Re: Fedora 33 System-Wide Change proposal: Make nano the default editor
On Mon, Aug 31, 2020 at 3:24 AM Neal Gompa wrote: > On Sun, Aug 30, 2020 at 8:15 PM Chris Murphy > wrote: > > > > Fedora-Silverblue-ostree-x86_64-33-20200830.n.0.iso does not have nano > > on the install media itself. Is it intentional? > > > > It's supposed to be there, but I don't know how Silverblue is > "defined" so it would be pulled in. I thought it'd get it from the > comps groups... > It should be there :/ : https://pagure.io/workstation-ostree-config/blob/f33/f/fedora-common-ostree-pkgs.yaml#_139 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Release criteria proposal: networking requirements
On Sat, Aug 29, 2020 at 4:34 AM Chris Murphy wrote: > On Fri, Aug 28, 2020 at 7:52 PM Chris Murphy > wrote: > > > The IPP Everywhere specification requires clients to support DNS-SD > > (mDNS is part of that) or WS-Discovery. Printers are required to > > support both DNS-SD and WS-Discovery. Avahi and systemd-resolved > > support DNS-SD, functionally equating DNS-SD and mDNS. > > From the spec: > > "Printers MUST publish a text (TXT) record that provides service > information over mDNS. > Printers that support dynamic DNS updates MUST publish separate TXT > records for each > domain that is updated." > > I'm not completely certain, but I'm wondering whether it's possible to > print IPP Everywhere at all, if DNS-SD or WS-Discovery aren't working > on the client. Even having the IP address might not be enough. > > I guess one way to test it would be to run the printing test case with > an IPP Everywhere printer, and try to print with avahi stopped. > Adding +Marek Kasik and +Zdenek Dohnal who might know the answer. Tom ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The case of LTO when produced enlarged binaries
On Sun, 2020-08-30 at 14:42 +0200, Igor Raits wrote: > On Sun, 2020-08-30 at 12:37 +0100, Tomasz Kłoczko wrote: > > On Fri, 24 Jul 2020 at 21:31, Igor Raits < > > ignatenkobr...@fedoraproject.org> > > wrote: > > [..] > > > > > Well, I tell what I see :) > > > > > > Compiling kitty with settings below produces this big > > > /usr/lib64/kitty/kitty/fast_data_types.so: > > > > > > * Without any LTO-related flags: 4.52 MB > > > * With -flto: 4.30 MB > > > * With -flto -ffat-lto-objects: 4.79 MB > > > > > > Well, I did not run compilation multiple times but don't think it > > > will > > > change much. > > > > > > > Comparing the size of the executable files does not make any sense. > > You should use the "size" command. > > Well, I'd use `size` command if I would care what section of a file > takes what size. In this case, I don't really care which section it is. > > All I care is that with -ffat-lto-objects, binary becomes bigger. Given this isn't a correctness issue, I haven't prioritized it. A quick look tells me all the difference is in the symbol table -- ie, the code, data and bss sections are the same size, but the symbol table is significantly larger. And AFAICT it's all debug symbols. In fact, it doesn't look like the debug info was stripped at all: [law@localhost kitty]$ objdump -h fast_data_types.so fast_data_types.so: file format elf64-x86-64 [ ... ] 26 .debug_aranges 01e0 000e2b64 2**0 CONTENTS, READONLY, DEBUGGING, OCTETS 27 .debug_info 000e60c7 000e2d44 2**0 CONTENTS, READONLY, DEBUGGING, OCTETS 28 .debug_abbrev 7543 001c8e0b 2**0 CONTENTS, READONLY, DEBUGGING, OCTETS 29 .debug_line 0007644f 001d034e 2**0 CONTENTS, READONLY, DEBUGGING, OCTETS 30 .debug_str0005cab8 0024679d 2**0 CONTENTS, READONLY, DEBUGGING, OCTETS 31 .debug_loc000d6477 002a3255 2**0 CONTENTS, READONLY, DEBUGGING, OCTETS 32 .debug_ranges 0003a000 003796cc 2**0 CONTENTS, READONLY, DEBUGGING, OCTETS 33 .debug_macro 0002b64f 003b36cc 2**0 CONTENTS, READONLY, DEBUGGING, OCTETS So someone needs to figure out why debug symbols aren't being stripped. I manually stripped the bits in kitty and after doing so the sizes of the resultant DSOs are the same (as I'd expect them to be) across the two builds. jeff ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Can a bugzilla issue be locked because of spam?
This old issue (https://bugzilla.redhat.com/show_bug.cgi?id=1177202) keeps receiving spam every couple of weeks from a different account. I've been trying to flag the spam comments as spam, and remove the flags they keep setting, and remove their CC as well, so they don't get follow-ups and get encouraged to continue spamming. However, they keep doing it. It's really quite annoying. Is there any way it can be locked or restricted to committers? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: Make nano the default editor
On Sun, Aug 30, 2020 at 8:15 PM Chris Murphy wrote: > > Fedora-Silverblue-ostree-x86_64-33-20200830.n.0.iso does not have nano > on the install media itself. Is it intentional? > It's supposed to be there, but I don't know how Silverblue is "defined" so it would be pulled in. I thought it'd get it from the comps groups... -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[389-devel] Re: Odd behaviour in import
> On 28 Aug 2020, at 19:23, Ludwig Krispenz wrote: > > > On 27.08.20 04:01, William Brown wrote: >> Hey there, >> >> I'm seeing some odd behaviour in an import test. I'm seeing that a large >> number of entries won't import unless the directory is restarted before the >> import task is performed. >> >> The error appears to be: >> >> [25/Aug/2020:14:14:58.973490600 +1000] - WARN - import_foreman - import >> userRoot: Skipping entry "cn=group0,ou=Groups,dc=example,dc=com" which has >> no parent, ending at line 154 of file >> "/opt/dirsrv/var/lib/dirsrv/slapd-standalone1/ldif/4f8afb8d-ec97-4246-94a2-ec343c0eacb4.ldif" >> ... >> [25/Aug/2020:14:14:59.307477400 +1000] - INFO - bdb_import_main - import >> userRoot: Import complete. Processed 14 entries (10 were skipped) in 1 >> seconds. (14.00 entries/sec) >> >> >> This is where a newly created backend *with* example entries, then has it's >> entire content overwriten during an import. Anything that is underneath the >> ou=* entries is not imported, but the ou= and dc=are fine. >> >> I'm wondering if this is something related to the fact we are replacing the >> ou= entries with different ids/nsunique ids. IE >> >> id 3 >> rdn: ou=groups >> objectClass: top >> objectClass: organizationalunit >> ou: groups >> aci: (targetattr="cn || member || gidNumber || nsUniqueId || >> description || ob >> jectClass")(targetfilter="(objectClass=groupOfNames)")(version 3.0; >> acl "Enab >> le anyone group read"; allow (read, search, >> compare)(userdn="ldap:///anyone;) >> ;) >> aci: >> (targetattr="member")(targetfilter="(objectClass=groupOfNames)")(version >> 3.0; acl "Enable group_modify to alter members"; allow >> (write)(groupdn="ldap: >> ///cn=group_modify,ou=permissions,dc=example,dc=com");) >> aci: (targetattr="cn || member || gidNumber || description || >> objectClass")(ta >> rgetfilter="(objectClass=groupOfNames)")(version 3.0; acl "Enable >> group_admin >>to manage groups"; allow (write, add, >> delete)(groupdn="ldap:///cn=group_admi >> n,ou=permissions,dc=example,dc=com");) >> creatorsName: cn=directory manager >> modifiersName: cn=directory manager >> createTimestamp: 20200827015033Z >> modifyTimestamp: 20200827015033Z >> nsUniqueId: b0fce42b-e80711ea-8141c872-2df18128 >> parentid: 1 >> entryid: 3 >> numSubordinates: 1 >> >> Becomes: >> >> id 4 >> rdn: ou=Groups >> createTimestamp: 20200224023755Z >> creatorsName: cn=Manager,dc=example,dc=com >> entryUUID: 67cc2212-eafa-1039-8830-152569770969 >> modifiersName: cn=Manager,dc=example,dc=com >> modifyTimestamp: 20200224023755Z >> objectClass: organizationalUnit >> objectClass: top >> ou: Groups >> nsUniqueId: 87b64988-e68911ea-a943c898-6d74ab17 >> parentid: 1 >> entryid: 4 >> >> >> Given that these id's are changing I'm wondering if this is somehow breaking >> our import ordering? Any ideas on where I should start to investigate this? > shouldn't the nsuniqueid be preserved ? Otherwise you could not use import to > initilaize a replica. The use case that's happening is that after a backend is setup with sample entries, then you try to restore from a backup or ldif of different origin. So the nsunique and entryid's both could and probably will change in this case. >> >> Thanks! >> >> — >> Sincerely, >> >> William Brown >> >> Senior Software Engineer, 389 Directory Server >> SUSE Labs >> ___ >> 389-devel mailing list -- 389-devel@lists.fedoraproject.org >> To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org >> Fedora Code of Conduct: >> https://docs.fedoraproject.org/en-US/project/code-of-conduct/ >> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines >> List Archives: >> https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org > ___ > 389-devel mailing list -- 389-devel@lists.fedoraproject.org > To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org — Sincerely, William Brown Senior Software Engineer, 389 Directory Server SUSE Labs ___ 389-devel mailing list -- 389-devel@lists.fedoraproject.org To unsubscribe send an email to 389-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/389-devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: Make nano the default editor
Fedora-Silverblue-ostree-x86_64-33-20200830.n.0.iso does not have nano on the install media itself. Is it intentional? -- Chris Murphy ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: systemd-resolved
On Sun, Aug 30, 2020 at 12:30 pm, Andreas Tunek wrote: On my F33 test system (new install yesterday) I can see my NAS but I can't connect to it. Could that be due to this change? Possibly! Try using 'resolvectl query' and see what it says ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1873888] perl-HTML-Parser-3.75 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1873888 Upstream Release Monitoring changed: What|Removed |Added Summary|perl-HTML-Parser-3.74 is|perl-HTML-Parser-3.75 is |available |available --- Comment #1 from Upstream Release Monitoring --- Latest upstream release: 3.75 Current version/release in rawhide: 3.72-21.fc32 URL: http://search.cpan.org/dist/HTML-Parser/ Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/2967/ -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1873888] New: perl-HTML-Parser-3.74 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1873888 Bug ID: 1873888 Summary: perl-HTML-Parser-3.74 is available Product: Fedora Version: rawhide Status: NEW Component: perl-HTML-Parser Keywords: FutureFeature, Triaged Assignee: jples...@redhat.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: caillon+fedoraproj...@gmail.com, caol...@redhat.com, john.j5l...@gmail.com, jples...@redhat.com, ka...@ucw.cz, perl-devel@lists.fedoraproject.org, rhug...@redhat.com, rstr...@redhat.com, sandm...@redhat.com Target Milestone: --- Classification: Fedora Latest upstream release: 3.74 Current version/release in rawhide: 3.72-21.fc32 URL: http://search.cpan.org/dist/HTML-Parser/ Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/2967/ -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1873854] perl-Test-Dependencies-0.28 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1873854 Upstream Release Monitoring changed: What|Removed |Added Summary|perl-Test-Dependencies-0.26 |perl-Test-Dependencies-0.28 |is available|is available --- Comment #2 from Upstream Release Monitoring --- Latest upstream release: 0.28 Current version/release in rawhide: 0.24-2.fc32 URL: http://search.cpan.org/dist/Test-Dependencies/ Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/3389/ -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[EPEL-devel] Re: Continuing playground discussion
On Fri, Aug 28, 2020 at 03:11:49PM -0700, Troy Dawson wrote: > > Pros for building against stream: > > - We would have a way to test EPEL packages that matter against the > > not yet released RHEL version. > > -- How often would this matter? > > -- It's hard to say. There might not be a single EPEL package needing > > this for the entire RHEL 8.3 release. > > -- I know for the 8.2 release, I would have liked it so I would have > > had a place to let others test my updated KDE. > > --- But I found a work around, so I didn't have to have it. > > > > Cons for building against stream: > > - I think you've hit on a big thing. For those wanting a major > > change, but don't care about stream, then playground becomes useless. > > -- So this cuts down on the usefulness of playground. Packagers who > > want a major change in their package, and are working on stream. > > - HERE IS THE BIGGEST CON AGAINST USING STREAM > > -- CentOS Stream is only going to be based on RHEL8 until RHEL9 comes > > out. At some point after that, it switches to being based off RHEL9. > > --- This means that infrastructure is going to have to switch > > everything back to being built off RHEL. > > --- We will have to re-document things. > > --- More confusion if we had go the CentOS Stream route. > > > > Troy > > At the EPEL Steering Committee Meeting, this was discussed again. > I believe we all agree that having -playground build off Stream isn't > a good thing. > But we are also concerned about possible library changes in RHEL8 that > might affect EPEL8 packages, and having something based off Stream > would be good. > Here is the proposal. > Note: A) was re-written with better wording than above. > > A) epel8-playground > 1 - Manual builds only. No package.cfg files. No automatic builds. > 2 - Assume playground depends on epel8. > 3 - Built off RHEL8 and CentOS Devel, just like epel8 is built. > > E) epel8-next > 1 - Manual builds only. No package.cfg files. No automatic builds. > 2 - Assume -next depends on epel. > 3 - Built off CentOS Stream. > 4 - Has a limited lifetime that corresponds with the CentOS Stream / > RHEL lifetime. > -- In other words, after CentOS Stream switches from RHEL8 to RHEL9, > then epel8-next get's archived. > > If people are wondering about the name, it was decided to use -next > instead of -stream, due to the overuse of 'stream' among other > reasons. > > Thoughts? Well, I think it satisfies all the use cases, but... we barely have enough cycles to try and revamp playground. Do we think we have enough to do that and also make a new -next version? Also, if we do make it, perhaps we should think what critera we would use to determine it's successfull? 10 packages using it? more than 1? Perhaps we could gather a 'I would use this' list from maintainers before we implement it? kevin signature.asc Description: PGP signature ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
Re: %lua_requires behaves differently in F33+
Aug 30, 2020 02:04:36 Miro Hrončok : Establish a FAS group for "Lua provenpackagers". Make sure the name it not to be confused with the Lua SIG, but note that the FAS group usually needs to be called ...-sig. I'd go with lua-packagres-sig or lua-maintainers-sig. Get it a mailing list needed for Bugzilla, e.g. lua-packagres-sig@lists. Don't mention it anywhere :) Well, it is mentioned here :) I'll go with packagers. lua-maintainers-sig is too close to the lua-maintainers@ email alias for those with commit access to the lia RPM. Thanks! -- Michel Alexandre Salim profile: https://keybase.io/michel_slm chat via email: https://delta.chat/ GPG key: 5DCE 2E7E 9C3B 1CFF D335 C1D7 8B22 9D2F 7CCC 04F2 ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: systemd-resolved
On 30.08.2020 16:04, Michael Catanzaro wrote: > The file should not be generated by NetworkManager. NetworkManager > should notice that the file is a symlink to > /run/systemd/resolve/stub-resolv.conf and leave it alone. (In point 3. > the file should be a symlink.) Network Manager can be configured to use an external resolv.conf generator for example by adding a new config file /etc/NetworkManager/conf.d/99-resolved.conf: [main] dns=systemd-resolved After adding this option you don't need to make /etc/resolv.conf a symbolic link to /run/NetworkManager/resolv.conf. -- Sincerely, Vitaly Zaitsev (vit...@easycoding.org) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora-IoT-34-20200830.0 compose check report
Missing expected images: Iot dvd x86_64 Iot dvd aarch64 Failed openQA tests: 2/16 (x86_64) Old failures (same test failed in Fedora-IoT-34-20200829.0): ID: 651109 Test: x86_64 IoT-dvd_ostree-iso iot_clevis URL: https://openqa.fedoraproject.org/tests/651109 ID: 65 Test: x86_64 IoT-dvd_ostree-iso iot_rpmostree_overlay URL: https://openqa.fedoraproject.org/tests/65 Passed openQA tests: 14/16 (x86_64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1873854] perl-Test-Dependencies-0.26 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1873854 Upstream Release Monitoring changed: What|Removed |Added Summary|perl-Test-Dependencies-0.25 |perl-Test-Dependencies-0.26 |is available|is available --- Comment #1 from Upstream Release Monitoring --- Latest upstream release: 0.26 Current version/release in rawhide: 0.24-2.fc32 URL: http://search.cpan.org/dist/Test-Dependencies/ Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/3389/ -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
[Bug 1873195] perl-Catalyst-Plugin-Session-State-Cookie-0.18 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1873195 Emmanuel Seyman changed: What|Removed |Added Status|NEW |CLOSED Fixed In Version||perl-Catalyst-Plugin-Sessio ||n-State-Cookie-0.18-1.fc34 Resolution|--- |RAWHIDE Doc Type|--- |If docs needed, set a value Last Closed||2020-08-30 11:17:10 --- Comment #1 from Emmanuel Seyman --- Built for rawhide: https://koji.fedoraproject.org/koji/buildinfo?buildID=1602871 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: systemd-resolved
On my F33 test system (new install yesterday) I can see my NAS but I can't connect to it. Could that be due to this change? Best regards Andreas ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: systemd-resolved
On Sun, Aug 30, 2020 at 9:06 am, Michael Catanzaro wrote: I don't know what to do about this. Ideally we would figure out what's wrong and sneak a freeze exception into the beta release. If the file in 3. is not a symlink, then that would be what's wrong, but it ought to be a symlink. I just did a test install. From the live environment, post-installation, I see: $ pwd /mnt/sysroot/etc $ ls -l | grep resolv -rw-r--r--. 1 root root 729 Aug 30 11:19 resolv.conf So the file is indeed not a symlink. That tells NetworkManager that the file is to be managed by NetworkManager, not by systemd. So basically you discovered our change is totally broken. Thanks for testing. I've reported https://bugzilla.redhat.com/show_bug.cgi?id=1873856. Michael ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: systemd-resolved
On Sat, Aug 29, 2020 at 3:12 pm, Chris Murphy wrote: Are these the expected behavior? 4. is unexpected. The file should not be generated by NetworkManager. NetworkManager should notice that the file is a symlink to /run/systemd/resolve/stub-resolv.conf and leave it alone. (In point 3. the file should be a symlink.) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Fedora 33 System-Wide Change proposal: systemd-resolved
On Sun, Aug 30, 2020 at 9:04 am, Michael Catanzaro wrote: 4. is unexpected. The file should not be generated by NetworkManager. NetworkManager should notice that the file is a symlink to /run/systemd/resolve/stub-resolv.conf and leave it alone. (In point 3. the file should be a symlink.) I don't know what to do about this. Ideally we would figure out what's wrong and sneak a freeze exception into the beta release. If the file in 3. is not a symlink, then that would be what's wrong, but it ought to be a symlink. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1873854] New: perl-Test-Dependencies-0.25 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1873854 Bug ID: 1873854 Summary: perl-Test-Dependencies-0.25 is available Product: Fedora Version: rawhide Status: NEW Component: perl-Test-Dependencies 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.25 Current version/release in rawhide: 0.24-2.fc32 URL: http://search.cpan.org/dist/Test-Dependencies/ Please consult the package updates policy before you issue an update to a stable branch: https://docs.fedoraproject.org/en-US/fesco/Updates_Policy/ More information about the service that created this bug can be found at: https://fedoraproject.org/wiki/Upstream_release_monitoring Please keep in mind that with any upstream change, there may also be packaging changes that need to be made. Specifically, please remember that it is your responsibility to review the new version to ensure that the licensing is still correct and that no non-free or legally problematic items have been added upstream. Based on the information from anitya: https://release-monitoring.org/project/3389/ -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: The case of LTO when produced enlarged binaries
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Sun, 2020-08-30 at 12:37 +0100, Tomasz Kłoczko wrote: > On Fri, 24 Jul 2020 at 21:31, Igor Raits < > ignatenkobr...@fedoraproject.org> > wrote: > [..] > > > Well, I tell what I see :) > > > > Compiling kitty with settings below produces this big > > /usr/lib64/kitty/kitty/fast_data_types.so: > > > > * Without any LTO-related flags: 4.52 MB > > * With -flto: 4.30 MB > > * With -flto -ffat-lto-objects: 4.79 MB > > > > Well, I did not run compilation multiple times but don't think it > > will > > change much. > > > > Comparing the size of the executable files does not make any sense. > You should use the "size" command. Well, I'd use `size` command if I would care what section of a file takes what size. In this case, I don't really care which section it is. All I care is that with -ffat-lto-objects, binary becomes bigger. > kloczek > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: > https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl9LnrEACgkQEV1auJxc Hh53yw//cmMnlkGgq0/BiSIv3SOAPhB786QkhnIGx9QhntOx/6akOFyxp4Td5xDB tb/tpoTaZUoDS0FMT03Q2+BVEC6aYnLU3Q/g8gSYrNi+Oyscd8PMztIS+XVnrAhy kb21ZrEkbhVP+tLGNqtpOjvBdkG6lEttDUAZLx2KGl8xBA+qcTWdnt2ZyvkYjQyj rNYM+yvN08phsk8JpEeb8yNwTzfy5FaPx+/TrFhNzCRgx68ttWckEfJqLn0RqIfU bdDw/pVYTW9WmZDzq8kBuBS3t1k/hs2/Jdyqs3NlfXIjBe4BaSJ17JqdwZIUaKnC c4m3Npl/U2ENJ8wHGNkZPF8BcJK29PlXU8BGGrfRADIzs2JjnFDHC6kuxScybfKI Reyhhp70U3mMWeuzoHvZO1hOW88gzqAVbO8bQWYzDzLGEim0Uwa738BuMIZeh5tN hJ2flGM2vve7u1jXNvdis/8WidkptPObis6egH82hoTtmp4KWhjKVEgU6NK9AYpI NurwZzdiMrYXdP0D9iAEYvTWuivi8nYIBLJ3P3AZGYKn+O790Mbv97emrSgxQdrf rK6KsIUbH+ggR+k91YoT1iZaITjrGKaQOb/YAfOytkxBXMK5B/xZ0dpnzUXBHdy+ OgJfeUx9rlrYwVUUpn2KxZSbM+KgF4/mWIgg/fyREoZYuMHeVuo= =sRls -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora-Rawhide-20200830.n.0 compose check report
No missing expected images. Compose FAILS proposed Rawhide gating check! 8 of 43 required tests failed openQA tests matching unsatisfied gating requirements shown with **GATING** below Failed openQA tests: 31/181 (x86_64) New failures (same test not failed in Fedora-Rawhide-20200828.n.2): ID: 650925 Test: x86_64 Server-dvd-iso support_server URL: https://openqa.fedoraproject.org/tests/650925 ID: 650928 Test: x86_64 Server-dvd-iso install_repository_nfs_graphical URL: https://openqa.fedoraproject.org/tests/650928 ID: 650929 Test: x86_64 Server-dvd-iso install_repository_nfs_variation URL: https://openqa.fedoraproject.org/tests/650929 ID: 650930 Test: x86_64 Server-dvd-iso install_repository_nfsiso_variation URL: https://openqa.fedoraproject.org/tests/650930 ID: 650934 Test: x86_64 Server-dvd-iso install_updates_nfs URL: https://openqa.fedoraproject.org/tests/650934 ID: 650940 Test: x86_64 Server-dvd-iso modularity_tests URL: https://openqa.fedoraproject.org/tests/650940 ID: 650945 Test: x86_64 Server-dvd-iso server_cockpit_updates URL: https://openqa.fedoraproject.org/tests/650945 ID: 650968 Test: x86_64 Workstation-live-iso install_default@uefi **GATING** URL: https://openqa.fedoraproject.org/tests/650968 ID: 650977 Test: x86_64 Workstation-live-iso base_update_cli **GATING** URL: https://openqa.fedoraproject.org/tests/650977 ID: 650980 Test: x86_64 Workstation-live-iso desktop_notifications_postinstall URL: https://openqa.fedoraproject.org/tests/650980 ID: 650983 Test: x86_64 Workstation-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/650983 ID: 650996 Test: x86_64 KDE-live-iso base_update_cli **GATING** URL: https://openqa.fedoraproject.org/tests/650996 ID: 650999 Test: x86_64 KDE-live-iso desktop_browser **GATING** URL: https://openqa.fedoraproject.org/tests/650999 ID: 651003 Test: x86_64 KDE-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/651003 ID: 651012 Test: x86_64 Silverblue-dvd_ostree-iso desktop_browser URL: https://openqa.fedoraproject.org/tests/651012 ID: 651015 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud **GATING** URL: https://openqa.fedoraproject.org/tests/651015 ID: 651020 Test: x86_64 Cloud_Base-qcow2-qcow2 base_update_cli_cloud URL: https://openqa.fedoraproject.org/tests/651020 ID: 651025 Test: x86_64 universal support_server URL: https://openqa.fedoraproject.org/tests/651025 ID: 651039 Test: x86_64 universal install_iscsi URL: https://openqa.fedoraproject.org/tests/651039 ID: 651076 Test: x86_64 universal install_pxeboot URL: https://openqa.fedoraproject.org/tests/651076 ID: 651077 Test: x86_64 universal install_pxeboot@uefi URL: https://openqa.fedoraproject.org/tests/651077 ID: 651084 Test: x86_64 universal install_kickstart_nfs URL: https://openqa.fedoraproject.org/tests/651084 Old failures (same test failed in Fedora-Rawhide-20200828.n.2): ID: 650942 Test: x86_64 Server-dvd-iso server_role_deploy_database_server **GATING** URL: https://openqa.fedoraproject.org/tests/650942 ID: 650946 Test: x86_64 Server-dvd-iso server_database_client **GATING** URL: https://openqa.fedoraproject.org/tests/650946 ID: 650972 Test: x86_64 Workstation-live-iso apps_startstop URL: https://openqa.fedoraproject.org/tests/650972 ID: 651000 Test: x86_64 KDE-live-iso desktop_notifications_postinstall URL: https://openqa.fedoraproject.org/tests/651000 ID: 651006 Test: x86_64 Silverblue-dvd_ostree-iso release_identification URL: https://openqa.fedoraproject.org/tests/651006 ID: 651032 Test: x86_64 universal upgrade_2_server_domain_controller URL: https://openqa.fedoraproject.org/tests/651032 ID: 651042 Test: x86_64 universal install_mirrorlist_graphical **GATING** URL: https://openqa.fedoraproject.org/tests/651042 ID: 651073 Test: x86_64 universal install_cyrillic_language URL: https://openqa.fedoraproject.org/tests/651073 ID: 651100 Test: x86_64 universal upgrade_2_realmd_client URL: https://openqa.fedoraproject.org/tests/651100 Soft failed openQA tests: 18/181 (x86_64) (Tests completed, but using a workaround for a known bug) New soft failures (same test not soft failed in Fedora-Rawhide-20200828.n.2): ID: 650936 Test: x86_64 Server-dvd-iso install_vncconnect_client URL: https://openqa.fedoraproject.org/tests/650936 ID: 650958 Test: x86_64 Server-dvd-iso install_vnc_client URL: https://openqa.fedoraproject.org/tests/650958 ID: 650981 Test: x86_64 Workstation-live-iso desktop_printing URL: https://openqa.fedoraproject.org/tests/650981 ID: 651026 Test: x86_64 universal upgrade_2_desktop_64bit URL: https://openqa.fedoraproject.org/tests/651026 Old soft failures (same test soft failed in Fedora-Rawhide-20200828.n.2): ID: 650969 Test: x86_64 Workstation-live-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/650969 ID: 651004 Test:
Fedora rawhide compose report: 20200830.n.0 changes
OLD: Fedora-Rawhide-20200828.n.2 NEW: Fedora-Rawhide-20200830.n.0 = SUMMARY = Added images:0 Dropped images: 1 Added packages: 7 Dropped packages:10 Upgraded packages: 73 Downgraded packages: 0 Size of added packages: 17.07 MiB Size of dropped packages:725.14 KiB Size of upgraded packages: 1.83 GiB Size of downgraded packages: 0 B Size change of upgraded packages: -50.16 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = = DROPPED IMAGES = Image: LXQt raw-xz armhfp Path: Spins/armhfp/images/Fedora-LXQt-armhfp-Rawhide-20200828.n.2-sda.raw.xz = ADDED PACKAGES = Package: ghc-atomic-write-0.2.0.7-1.fc34 Summary: Atomically write to a file RPMs:ghc-atomic-write ghc-atomic-write-devel ghc-atomic-write-doc ghc-atomic-write-prof Size:561.92 KiB Package: ghc-data-fix-0.2.1-1.fc34 Summary: Fixpoint data types RPMs:ghc-data-fix ghc-data-fix-devel ghc-data-fix-doc ghc-data-fix-prof Size:476.22 KiB Package: ghc-modern-uri-0.3.2.0-1.fc34 Summary: Modern library for working with URIs RPMs:ghc-modern-uri ghc-modern-uri-devel ghc-modern-uri-doc ghc-modern-uri-prof Size:9.91 MiB Package: ghc-pretty-simple-3.2.3.0-1.fc34 Summary: Pretty printer for data types with a 'Show' instance RPMs:ghc-pretty-simple ghc-pretty-simple-devel ghc-pretty-simple-doc ghc-pretty-simple-prof Size:3.60 MiB Package: ghc-text-manipulate-0.2.0.1-2.fc34 Summary: Case conversion, word boundary manipulation, and textual subjugation RPMs:ghc-text-manipulate ghc-text-manipulate-devel ghc-text-manipulate-doc ghc-text-manipulate-prof Size:1.94 MiB Package: qt-avif-image-plugin-0.3.1-1.fc34 Summary: Qt plug-in to read/write AVIF images RPMs:qt-avif-image-plugin Size:170.94 KiB Package: wlr-sunclock-0.1.1-4.fc34 Summary: Show the sun's shadows on earth RPMs:wlr-sunclock Size:442.74 KiB = DROPPED PACKAGES = Package: lua-lunit-0.5-17.fc32 Summary: Unit testing framework for Lua RPMs:lua-lunit Size:16.66 KiB Package: php-icewind-searchdav-0.3.1-7.fc33 Summary: A sabre/dav plugin to implement rfc5323 SEARCH RPMs:php-icewind-searchdav Size:18.94 KiB Package: php-icewind-smb-1.1.2-9.fc33 Summary: php wrapper for smbclient and libsmbclient-php RPMs:php-icewind-smb Size:26.47 KiB Package: php-phpunit-php-code-coverage8-8.0.2-1.fc33 Summary: PHP code coverage information RPMs:php-phpunit-php-code-coverage8 Size:203.18 KiB Package: php-sabre-dav-3.2.3-6.fc32 Summary: WebDAV Framework for PHP RPMs:php-sabre-dav Size:275.40 KiB Package: php-sabre-event-2.0.2-12.fc33 Summary: Lightweight library for event-based programming RPMs:php-sabre-event Size:14.91 KiB Package: php-sabre-http-4.2.4-9.fc33 Summary: Library for dealing with http requests and responses RPMs:php-sabre-http Size:38.19 KiB Package: php-sabre-uri-1.2.1-10.fc33 Summary: Functions for making sense out of URIs RPMs:php-sabre-uri Size:14.97 KiB Package: php-sabre-vobject-3.5.3-15.fc33 Summary: Library to parse and manipulate iCalendar and vCard objects RPMs:php-sabre-vobject Size:89.02 KiB Package: php-sabre-xml-1.5.1-8.fc33 Summary: XML library that you may not hate RPMs:php-sabre-xml Size:27.40 KiB = UPGRADED PACKAGES = Package: assertj-core-3.17.0-1.fc34 Old package: assertj-core-3.16.1-5.fc33 Summary: Library of assertions similar to fest-assert RPMs: assertj-core assertj-core-javadoc Size: 2.48 MiB Size change: 147.28 KiB Changelog: * Sun Aug 23 2020 Fabio Valentini - 3.17.0-1 - Update to version 3.17.0. Package: bijiben-3.37.91-1.fc34 Old package: bijiben-3.37.90-1.fc34 Summary: Simple Note Viewer RPMs: bijiben Size: 2.07 MiB Size change: 44.09 KiB Changelog: * Sat Aug 29 2020 Kalev Lember - 3.37.91-1 - Update to 3.37.91 Package: cdi-api-2.0-1.fc34 Old package: cdi-api-1.2-14.fc33 Summary: Contexts and Dependency Injection API RPMs: cdi-api cdi-api-javadoc Size: 529.18 KiB Size change: 20.52 KiB Changelog: * Sun Aug 23 2020 Fabio Valentini - 2.0-1 - Update to version 2.0. Package: chromium-85.0.4183.83-1.fc34 Old package: chromium-84.0.4147.135-1.fc34 Summary: A WebKit (Blink) powered web browser RPMs: chrome-remote-desktop chromedriver chromium chromium-common chromium-headless Size: 413.52 MiB Size change: -2.76 MiB Changelog: * Wed Aug 26 2020 Tom Callaway - 85.0.4183.83-1 - update to 85.0.4183.83 Package: clevis-pin-tpm2-0.1.3-1.fc34 Old package: clevis-pin-tpm2-0.1.2-2.fc34 Summary: Clevis PIN for unlocking with TPM2 supporting Authorized Policies RPMs: clevis-pin-tpm2 Size: 1.94 MiB Size change: -10.35 KiB Changelog: * Sat Aug 29 2020 Peter Robinson - 0.1.3-1 - Update to 0.1.3 Package: dconf-editor-3.37.91-1.fc34 Old package: dconf-editor-3.36.4-2.fc33 Summary
Re: The case of LTO when produced enlarged binaries
On Fri, 24 Jul 2020 at 21:31, Igor Raits wrote: [..] > Well, I tell what I see :) > > Compiling kitty with settings below produces this big > /usr/lib64/kitty/kitty/fast_data_types.so: > > * Without any LTO-related flags: 4.52 MB > * With -flto: 4.30 MB > * With -flto -ffat-lto-objects: 4.79 MB > > Well, I did not run compilation multiple times but don't think it will > change much. > Comparing the size of the executable files does not make any sense. You should use the "size" command. kloczek -- Tomasz Kłoczko | LinkedIn: http://lnkd.in/FXPWxH > > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: The case of LTO when produced enlarged binaries
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On Fri, 2020-07-24 at 14:32 -0600, Jeff Law wrote: > On Fri, 2020-07-24 at 22:30 +0200, Igor Raits wrote: > > On Fri, 2020-07-24 at 14:27 -0600, Jeff Law wrote: > > > On Fri, 2020-07-24 at 22:24 +0200, Igor Raits wrote: > > > > On Fri, 2020-07-24 at 13:29 -0600, Jeff Law wrote: > > > > > On Fri, 2020-07-24 at 19:12 +, Artem Tim wrote: > > > > > > Hi. In rare cases building packages with LTO producing > > > > > > binaries > > > > > > or > > > > > > libraries which have bigger size then if they have built > > > > > > without > > > > > > LTO. For example 'kitty' package: > > > > > > > > > > > > * with LTO: > > > > > > - koji task > > > > > > https://koji.fedoraproject.org/koji/taskinfo?taskID=47762998 > > > > > > 1.79 MB glfw-wayland.so > > > > > > 1.99 MB glfw-x11.so > > > > > > 4.78 MB fast_data_types.so > > > > > > 8.56 MB total > > > > > > > > > > > > * no LTO > > > > > > - koji > > > > > > https://koji.fedoraproject.org/koji/taskinfo?taskID=47769854 > > > > > > 1.65 MB glfw-wayland.so > > > > > > 1.84 MB glfw-x11.so > > > > > > 4.51 MB fast_data_types.so > > > > > > 8.00 MB total > > > > > > > > > > > > Difference is 7%. What we should do in such case? Should we > > > > > > disable > > > > > > LTO for such packages? Or there is still could be gains > > > > > > from > > > > > > faster > > > > > > code execution speed? > > > > > I'd tend to leave LTO on, but it's totally your call. > > > > > Without > > > > > looking at the > > > > > binaries, sources and compiler dumps I'd hazard a guess > > > > > you're > > > > > getting a lot of > > > > > cross module inlining, but very little identical code > > > > > folding. > > > > > THe > > > > > former tends > > > > > to make things bigger, but faster. The latter tends to > > > > > shrink > > > > > code > > > > > with little > > > > > impact on runtime performance. > > > > > > > > From what I see in this case, -ffat-lto-objects generates code > > > > that > > > > is > > > > bigger than without -flto. -flto alone generates smaller code > > > > than > > > > without -flto. > > > The fat-lto-objects bits are not used during an LTO link. They > > > exist > > > solely to > > > cover the case where there's a .o/.a that ends up installed. > > > > Well, I tell what I see :) > > > > Compiling kitty with settings below produces this big > > /usr/lib64/kitty/kitty/fast_data_types.so: > > > > * Without any LTO-related flags: 4.52 MB > > * With -flto: 4.30 MB > > * With -flto -ffat-lto-objects: 4.79 MB > > > > Well, I did not run compilation multiple times but don't think it > > will > > change much. > That's quite bizarre. I'll put it on the list of things to > investigate. Hi Jeff, Any news about this issue? > jeff > - -- Igor Raits -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEcwgJ58gsbV5f5dMcEV1auJxcHh4FAl9Li60ACgkQEV1auJxc Hh4q4A/6AyqFOE64rYb6gdhdlqJWKZovmucbeXMnpq6wD0zUqrpvaUyyAaSjGQ6D tLs+7RC8rFqErfPDUsnSll90+HiHqHRp1O6UOLjRQ8EwbSVZGQ0e0l5NfrktRy8i mjMG1r7KrKbuRQi3/4//lg8PQroVvXLqNIuwSpLYiDYA3loJAra0+pdP2mSdiWpk zAn8uAx5wOLNmWKqv+OS6SU3oiJXAOezBgDSoF70fgxAep7qgv6J+wjLrtkl2U1G 3atZ2r7+pfvI5UiFp9/0CXT0ZW9SQRoXMza0OURZpvUIk21f0nYjQgXv4gEWttf/ 7hOO4n+tg3xqurgb91j7WW9VNEiMbACYTidv/jxhAqOwBj6jeozh5e0YrmsRZ3Oa ZN74SWXl9k2Omh8By3EaNappHCLO9Oxr0DTkt+hc2JNTtmc9m5SPYnl4nd+N80wd iqv1Cg9wG46cL+Ofnz+L03F7rzsXN0ywwoKOZMGwkPsGrmOFcxko4iJ4j7tzUCiz K0iJFqeYoh6oPRGomZ1+KZP+mlKGaV9GZ0FhdIhCOB0MV0Yshk+4TdW5OQ5sYsby YLL12yN/WKCRsm16XH1bT8hu8Qu56bued0HOn9PrYDqz4txa2+d6QdOLUFTATiOY QfWO+31o236UkWSjxc+Wc34KHox5vr+ueNrnDUaKtwOc7jpqvJ0= =zrRd -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[Bug 1871716] perl-Mail-DKIM-1.20200824 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1871716 Emmanuel Seyman changed: What|Removed |Added Status|NEW |CLOSED Fixed In Version||perl-Mail-DKIM-1.20200824-1 ||.fc34 Resolution|--- |RAWHIDE Doc Type|--- |If docs needed, set a value Last Closed||2020-08-30 11:16:30 --- Comment #1 from Emmanuel Seyman --- Build for rawhide: https://koji.fedoraproject.org/koji/buildinfo?buildID=1602897 -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Fedora-Cloud-31-20200830.0 compose check report
No missing expected images. Failed openQA tests: 2/7 (x86_64) New failures (same test not failed in Fedora-Cloud-31-20200829.0): ID: 650916 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/650916 ID: 650921 Test: x86_64 Cloud_Base-qcow2-qcow2 base_update_cli_cloud URL: https://openqa.fedoraproject.org/tests/650921 Passed openQA tests: 5/7 (x86_64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Pointers on packaging an application for EL8
On 30. 08. 20 11:40, Alex Corcoles wrote: I might for the moment make something pip-installable from a URL, so I have something "useful" as soon as possible, and postpone RPM packaging to after that. I'd recommend making it pip installable from PyPI. That way you can have some CI (such as GitHub Action if GitHub is your git forge) to publish sdist / wheels to PyPI on every push to the default branch. With tools like setuptools_scm, you ensure that each newly created version on PyPI is automatically bumped. With git tags, you can control what versions are considered "stable" and what versions are considered "prereleases". -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
Re: Pointers on packaging an application for EL8
Hi Miro, > * Makes only sense to be installed using your distribution's package > manager > > Why? This is a requirement I don't understand. > That might be an overstatement. This is software to help install and configure other software, so it doesn't make sense if it has a complex installation procedure. Of course, installing using pip from an URL is a simple installation procedure, so I could go for that. > * Keep the packaging in the main source Git repo > > The RPM packaging or the Python (pip/poetry packaging)? > The RPM packaging. I don't often see many examples of software which is package-friendly out there. > > * Is there any project out there with similar goals doing things > "correctly" I could "copy"? > > I don't know any Python project with automatic Copr builds from git, but > maybe > look at a non-Python one? > > > https://copr.fedorainfracloud.org/coprs/dcantrell/rpminspect/package/rpminspect/ > https://github.com/rpminspect/rpminspect/blob/master/.copr/Makefile Oh, that's most useful, thanks! > > * pyproject-rpm-macros looks like something useful for what I want to > do, can it be used on to package for EL8? (I only see Fedora branches) > > It cannot. pyproject-rpm-macros heavaily relies on technology not yet > (fully) > available in EPEL 8 which is unfortunately now an ancient distribution > when it > comes to leading edge stuff :( > > - RPM buildrequires generators are missing (old RPM) > - new Python RPM dependency generators would have to be backported > ideally with parametric generators from Fedora 33+'s RPM > - RHEL 8 has an ancient pip version 9, it might work, > however nobody was brave enough to try it) > - tox 3.13+ is needed (EPEL 8 has tox 3.4) for %tox > > No worries, I just wanted to know if it was worth investigating that. Thanks! I might for the moment make something pip-installable from a URL, so I have something "useful" as soon as possible, and postpone RPM packaging to after that. Thanks! Álex ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
Re: Pointers on packaging an application for EL8
On 29. 08. 20 13:55, Alex Corcoles wrote: Hi, Hi Alex. I'm dabbling in writing a small Python application (further details below to provide some context). This application: * Has no dependencies other than the Python standard library * Makes only sense to be installed using your distribution's package manager Why? This is a requirement I don't understand. ... I would like: * Making it easy for developers to hack in the package. They should be able to use any Linux system to develop. I would provide scripts using containers (podman/docker) to run tests and create packages for all supported distros. Making it pip installable makes it very easy to run. Using poetry makes it very easy to hack on. * Keep the packaging in the main source Git repo The RPM packaging or the Python (pip/poetry packaging)? * Packaging should be fully automatized in CI/CD. All commits should generate packages for all supported distros (with a timestamped version) and push it to a repo (I would use COPR, ppa, etc.). Latest master should be easily installable using dnf, other branches should be easily installable for testing purposes. That should be easily achievable with pip-installable packages with the help of setuptools_scm (possibly poetry also has something like this). Not sure about dnf/rpm packages. Copr has some CI abilities. ... My questions (as a relative noob to RPM packaging- I've created and automated some RPM packaging, but mostly by winging it): * Is any of the above a terrible idea I should reconsider? That depends on the answer for my main question. * Is there any project out there with similar goals doing things "correctly" I could "copy"? I don't know any Python project with automatic Copr builds from git, but maybe look at a non-Python one? https://copr.fedorainfracloud.org/coprs/dcantrell/rpminspect/package/rpminspect/ https://github.com/rpminspect/rpminspect/blob/master/.copr/Makefile * pyproject-rpm-macros looks like something useful for what I want to do, can it be used on to package for EL8? (I only see Fedora branches) It cannot. pyproject-rpm-macros heavaily relies on technology not yet (fully) available in EPEL 8 which is unfortunately now an ancient distribution when it comes to leading edge stuff :( - RPM buildrequires generators are missing (old RPM) - new Python RPM dependency generators would have to be backported ideally with parametric generators from Fedora 33+'s RPM - RHEL 8 has an ancient pip version 9, it might work, however nobody was brave enough to try it) - tox 3.13+ is needed (EPEL 8 has tox 3.4) for %tox -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ python-devel mailing list -- python-devel@lists.fedoraproject.org To unsubscribe send an email to python-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/python-devel@lists.fedoraproject.org
Re: %lua_requires behaves differently in F33+
On Sun, Aug 30, 2020 at 11:04 AM Miro Hrončok wrote: > > On 30. 08. 20 4:07, Michel Alexandre Salim wrote: > > Quick question: for Python there's both python-devel and python-sig -- > > this seems overkill for Lua, right? Would starting lua@lists be enough? > > Not only it is overkill, but it brings problems. > For the story, see this ticket: > > https://pagure.io/fedora-infrastructure/issue/5478 > > tl;dr the python-devel list is open to anybody >the python-sig is a private (bugzilla mostly) list for the packaging > group >people are confused why cannot they see the python-sig list >even when they are members of the Python SIG > > For a new SIG I'd do the following: > > Establish a FAS group for "Lua provenpackagers". Make sure the name it not to > be > confused with the Lua SIG, but note that the FAS group usually needs to be > called ...-sig. I'd go with lua-packagres-sig or lua-maintainers-sig. Get it a > mailing list needed for Bugzilla, e.g. lua-packagres-sig@lists. Don't mention > it > anywhere :) > > Establish a general mailing list about Lua. Most likely lua@lists. Mention it > everywhere. > > > (Also, I couldn't find documentation on starting a new mailing list. > > Presumably an Infra pagure ticket?) > > Yes. You can look at the ticket I opened for creating the @java-maint-sig group and mailing list for inspiration :) https://pagure.io/fedora-infrastructure/issue/8902 We also have two mailing lists like python - java-devel@lists is the old list, for general and public discussion, and java-maint-sig@lists is the new private list for the group's bugzilla account. Fabio ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Fedora-Cloud-32-20200830.0 compose check report
No missing expected images. Soft failed openQA tests: 1/7 (x86_64) (Tests completed, but using a workaround for a known bug) Old soft failures (same test soft failed in Fedora-Cloud-32-20200829.0): ID: 650909 Test: x86_64 Cloud_Base-qcow2-qcow2 cloud_autocloud URL: https://openqa.fedoraproject.org/tests/650909 Passed openQA tests: 6/7 (x86_64) -- Mail generated by check-compose: https://pagure.io/fedora-qa/check-compose ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: %lua_requires behaves differently in F33+
On 30. 08. 20 4:07, Michel Alexandre Salim wrote: Quick question: for Python there's both python-devel and python-sig -- this seems overkill for Lua, right? Would starting lua@lists be enough? Not only it is overkill, but it brings problems. For the story, see this ticket: https://pagure.io/fedora-infrastructure/issue/5478 tl;dr the python-devel list is open to anybody the python-sig is a private (bugzilla mostly) list for the packaging group people are confused why cannot they see the python-sig list even when they are members of the Python SIG For a new SIG I'd do the following: Establish a FAS group for "Lua provenpackagers". Make sure the name it not to be confused with the Lua SIG, but note that the FAS group usually needs to be called ...-sig. I'd go with lua-packagres-sig or lua-maintainers-sig. Get it a mailing list needed for Bugzilla, e.g. lua-packagres-sig@lists. Don't mention it anywhere :) Establish a general mailing list about Lua. Most likely lua@lists. Mention it everywhere. (Also, I couldn't find documentation on starting a new mailing list. Presumably an Infra pagure ticket?) Yes. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
[EPEL-devel] Re: plasma has moved from epel into playground causing update conflicts
OK thanks for the tip...I'll check what else I use playground for and if only KDE will disable it...and if not will run update --nobest I guess... ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
[EPEL-devel] Re: plasma has moved from epel into playground causing update conflicts
Short answer, no, there is currently no way for me to remove it from playground. I wish I could. Unless you have a specific need, you shouldn't have playground enabled anymore. You don't need it for KDE anymore. I've given instructions via email and web pages on how to install KDE via regular EPEL8. And yet, when people do a good search, the one email I sent saying you should install it via epel-playground shows up in the top 4 spots. Please, disregard that email. There is no need for epel-playground to install KDE. On Fri, Aug 28, 2020 at 5:01 PM Andy Hall wrote: > > Can the below be fixed ? I guess this package should not be in both repos... > > # yum update > Last metadata expiration check: 0:10:02 ago on Fri 28 Aug 2020 23:47:51 BST. > Error: > Problem 1: package > plasma-workspace-geolocation-5.18.4.1-2.epel8.playground.x86_64 > requires libgps.so.24()(64bit), but none of the providers can be > installed > - cannot install both gpsd-libs-3.18.1-2.epel8.playground.1.x86_64 > and gpsd-libs-3.19-4.el8.1.x86_64 > - cannot install the best update candidate for package > plasma-workspace-geolocation-5.18.4.1-2.el8.x86_64 > - cannot install the best update candidate for package > gpsd-libs-3.19-4.el8.1.x86_64 > Problem 2: problem with installed package gpsd-libs-3.19-4.el8.1.x86_64 > - cannot install both gpsd-libs-3.18.1-2.epel8.playground.1.x86_64 > and gpsd-libs-3.19-4.el8.1.x86_64 > - cannot install both gpsd-libs-3.19-4.el8.1.x86_64 and > gpsd-libs-3.18.1-2.epel8.playground.1.x86_64 > - package plasma-workspace-geolocation-5.18.4.1-2.epel8.playground.x86_64 > requires libgps.so.24()(64bit), but none of the providers can be > installed > - package > plasma-workspace-geolocation-libs-5.18.4.1-2.epel8.playground.x86_64 > requires plasma-workspace-geolocation = 5.18.4.1-2.epel8.playground, > but none of the providers can be installed > - cannot install the best update candidate for package > plasma-workspace-geolocation-libs-5.18.4.1-2.el8.x86_64 > > # yum info plasma-workspace-geolocation > Last metadata expiration check: 0:14:17 ago on Fri 28 Aug 2020 23:47:51 BST. > Installed Packages > Name : plasma-workspace-geolocation > Version : 5.18.4.1 > Release : 2.el8 > Architecture : x86_64 > Size : 206 k > Source : plasma-workspace-5.18.4.1-2.el8.src.rpm > Repository : @System > From repo: epel > Summary : Plasma5 geolocation components > URL : https://cgit.kde.org/plasma-workspace.git > License : GPLv2+ > Description : Plasma5 geolocation components. > > Available Packages > Name : plasma-workspace-geolocation > Version : 5.18.4.1 > Release : 2.epel8.playground > Architecture : x86_64 > Size : 87 k > Source : plasma-workspace-5.18.4.1-2.epel8.playground.src.rpm > Repository : epel-playground > Summary : Plasma5 geolocation components > URL : https://cgit.kde.org/plasma-workspace.git > License : GPLv2+ > Description : Plasma5 geolocation components. > ___ > epel-devel mailing list -- epel-devel@lists.fedoraproject.org > To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org ___ epel-devel mailing list -- epel-devel@lists.fedoraproject.org To unsubscribe send an email to epel-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org
