[389-devel] Error building manpages in setup.py
make[2]: Leaving directory '/home/william/build/ds' make[1]: Leaving directory '/home/william/build/ds' make -j1 -C ~/build/ds lib389 make[1]: Entering directory '/home/william/build/ds' cd /home/william/development/389ds/ds/src/lib389; python3 setup.py build ; python3 setup.py build_manpages Traceback (most recent call last): File "setup.py", line 17, in from build_manpages import build_manpages ModuleNotFoundError: No module named 'build_manpages' Traceback (most recent call last): File "setup.py", line 17, in from build_manpages import build_manpages ModuleNotFoundError: No module named 'build_manpages' make[1]: *** [Makefile:14617: lib389] Error 1 make[1]: Leaving directory '/home/william/build/ds' make: *** [Makefile:51: ds] Error 2 What package provides build_manpages? pip search manpage sphinxcontrib-manpage (0.4) - Sphinx linux manpage extension manpage (0.1)- Functionality to create Unix manual pages. argparse-manpage (1.1) - Build manual page from python's ArgumentParser object. cli2man (0.2.4) - Converts the help message of a program into a manpage xmlmp (1.0) - Simple XML-based manpage authoring tools And then I'll need to work out the relevant rpm or dep (I've swapped to openSUSE also, so that'll be fun ;) Thanks! -- 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/message/J5RE6FCHLTAM3SKDKXMHIARJTMEO3X55/
Re: RFC: make $releasever return "rawhide" on Rawhide
On Thu, Aug 2, 2018 at 7:12 PM Kevin Fenzi wrote: > > On 08/02/2018 05:04 AM, Neal Gompa wrote: > > > This might surprise you, but I actually prefer the current way. It > > makes activating Rawhide an explicit action that can stay carried > > forward. > > The same for the proposed change, once you install fedora-release from > rawhide you are on rawhide until and unless you intentionally switch. > > >The other thing is, realistically, few third party folks try > > to build for Rawhide because Rawhide snapshots are either too old or > > too broken. > > > > Case in point, the Docker containers for Rawhide effectively look like > > Fedora 28, so what's the point? And upgrading to the latest released > > compose just breaks everything, so it's not useful there either. > > I've been looking into this the last week or so by chance. Rawhide does > compose containers every day with rawhide compose, they are just not > correctly uploading to our registry. Hopefully this will be fixed soon. > > I don't think the answer to something being old or broken is to sigh and > wander off. We need to fix those things, and I think we are making > progress on doing so. > > > This change makes no sense unless we were actually going to make > > Rawhide something that people could rely on. And I'm not sure that's a > > good idea, since we have a nice cadence of releasing every 6 > > months(-ish). It's already too hard to keep Rawhide working because of > > GCC breakages and the DNF stack work, and upstreams rely on our > > Rawhide tree to suss out these kinds of things. > > I'm not sure I follow here... you don't think we should make rawhide > something to rely on because we have regular releases? > I'm saying that if we try to pull off something similar to openSUSE Tumbleweed with our current infrastructure and tooling, upstreams like GCC and glibc could no longer leverage our Rawhide to validate their code. > In any case I think rawhide is very useful and without it our stable > releases would be vastly more diffcult. We can definitely do better to > make it stable, but I think it's quite usable. It's not usable whenever we have compiler transitions or add more weird GCC plugins, and that's something I've accepted will never change as long as we're the distribution that helps make GCC great. And that's fine. > > > > And I would argue that special casing Rawhide is sort of the point, > > but I have no objection to making dnf --releasever=rawhide distro-sync > > also work. I just don't think it's smart to drop the release number > > thing and the fedora-repos-rawhide package. > > The number will keep working too. We can make that an alias in > mirrormanager. So, for example if we had this implemented now and we > branched 29 off, '29' would point to the branched release, '30' or > 'rawhide' would point to rawhide. If you installed fedora-release from > rawhide it would keep you on rawhide, if you install from branched or > distro-sync to the branched fedora-release (by doing a 'dnf > --releasever=29 distro-sync fedora-release') you go on branched. This > means you don't need to worry about fedora-release-rawhide and > enabling/disabling repos, and makes everyone's life easier. > But the problem is that it does make things slightly harder. And you're not quite correct about this. The way that DNF gets this value is through identifying the package that provides "system-release" or "distribution-release" and identifies the version set for the package. That version is what propagates to set $releasever. Hilariously, PackageKit independently reads VERSION_ID from os-release(5) to determine this. These don't always agree. And in addition, it's impossible to stay on Rawhide through PackageKit without the controls through fedora-repos-rawhide forcing it. And how do you propose people sync down from Rawhide to "branched"? Or sync up from an old Rawhide to "branched"/"stable" which this change? From what I can tell, that wouldn't be easy. -- 真実はいつも一つ！/ 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://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/message/MQQFHZNTJS4AZ6Y52264LXNGOOHJBAO4/
[389-devel] Please review: 49881
A header check was missing from configure.ac. https://pagure.io/389-ds-base/issue/49881 https://pagure.io/389-ds-base/pull-request/49882 -- 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/message/KAZFSLX22VFUZ5SN24SMZHQ3NXCCHNWC/
[389-devel] 389 DS nightly 2018-08-03 - 90% PASS
https://fedorapeople.org/groups/389ds/ci/nightly/2018/08/03/report-389-ds-base-1.4.0.13-20180802gitb14c836.fc28.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/message/XYZUPDNXAHQZXQOLU4JBM6NB4TL3KQMY/
Re: F29 System Wide Change: Remove Excessive Linking
Rex Dieter wrote on Thu, Aug 02, 2018 at 10:14:13AM -0500: > Dominique Martinet wrote: > > In practice, `pkg-config --cflags foo` will only fetch cflags for > > dependencies listed in Requires, not Requires.private > > pkg-config --cflags foo > fetches cflags of Requires.private items in foo.pc for me. I see, that indeed appears to work on fedora, but not on the nixos box I tested (because having different include paths made testing easier there, but now I'm testing on fedora it looks OK there as you say) The difference between the two is that nixos is using the freedesktop pkg-config[1] while fedora uses pkgconf[2], so it would appear this isn't standard maybe? At which point the man page could use being more explicit about it... Oh, now I'm looking there's a (rather long) bug open about this here: https://bugs.freedesktop.org/show_bug.cgi?id=105572 [1] https://www.freedesktop.org/wiki/Software/pkg-config/ [2] https://github.com/pkgconf/pkgconf > I've patched many packages to use that feature, and haven't noticed any > breakage (so far). Well, packages can be fixed on the fedora side, but as upstream I wouldn't accept such a change until the freedesktop version behaves the same as I'd want to support users of either pkg-config version. Igor Gnatenko wrote on Thu, Aug 02, 2018 at 06:12:23PM +0200: > The real problem here is when you have complex frameworks like gtk. > > pkg-config basically will link you against gdk, gdk-pixbuf, gtk and a lot > of other stuff. But in practice, not every application need to link against > all of them. Yeah, complex frameworks are difficult with that, but upstream is actually dealing with it indirectly by switching to more modern build systems (for gtk, see gnome's MesonPorting[3] page) meson will automatically add --as-needed to the linker flags as appropriate (don't ask me what is appropriate), so we won't need to force it for them when they're done. Eventually some autotools/libtool macro could be added for other projects to use.. [3] https://wiki.gnome.org/Initiatives/GnomeGoals/MesonPorting -- Dominique Martinet ___ 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/message/MC4Z6HAQRVVHR7MOX5JEQ5FJ6WLLRFLJ/
[Bug 1611865] New: perl-Getopt-Long-Descriptive-0.103 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1611865 Bug ID: 1611865 Summary: perl-Getopt-Long-Descriptive-0.103 is available Product: Fedora Version: rawhide Component: perl-Getopt-Long-Descriptive Keywords: FutureFeature, Triaged Assignee: p...@city-fan.org Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: iarn...@gmail.com, p...@city-fan.org, perl-devel@lists.fedoraproject.org, trem...@tremble.org.uk Latest upstream release: 0.103 Current version/release in rawhide: 0.102-3.fc29 URL: http://search.cpan.org/dist/Getopt-Long-Descriptive 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/7110/ -- 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/message/OGRUIAFWRGZQSSNBWP6XF5WB7F4P6HPT/
Re: RFC: make $releasever return "rawhide" on Rawhide
On 08/02/2018 05:04 AM, Neal Gompa wrote: > This might surprise you, but I actually prefer the current way. It > makes activating Rawhide an explicit action that can stay carried > forward. The same for the proposed change, once you install fedora-release from rawhide you are on rawhide until and unless you intentionally switch. >The other thing is, realistically, few third party folks try > to build for Rawhide because Rawhide snapshots are either too old or > too broken. > > Case in point, the Docker containers for Rawhide effectively look like > Fedora 28, so what's the point? And upgrading to the latest released > compose just breaks everything, so it's not useful there either. I've been looking into this the last week or so by chance. Rawhide does compose containers every day with rawhide compose, they are just not correctly uploading to our registry. Hopefully this will be fixed soon. I don't think the answer to something being old or broken is to sigh and wander off. We need to fix those things, and I think we are making progress on doing so. > This change makes no sense unless we were actually going to make > Rawhide something that people could rely on. And I'm not sure that's a > good idea, since we have a nice cadence of releasing every 6 > months(-ish). It's already too hard to keep Rawhide working because of > GCC breakages and the DNF stack work, and upstreams rely on our > Rawhide tree to suss out these kinds of things. I'm not sure I follow here... you don't think we should make rawhide something to rely on because we have regular releases? In any case I think rawhide is very useful and without it our stable releases would be vastly more diffcult. We can definitely do better to make it stable, but I think it's quite usable. > > And I would argue that special casing Rawhide is sort of the point, > but I have no objection to making dnf --releasever=rawhide distro-sync > also work. I just don't think it's smart to drop the release number > thing and the fedora-repos-rawhide package. The number will keep working too. We can make that an alias in mirrormanager. So, for example if we had this implemented now and we branched 29 off, '29' would point to the branched release, '30' or 'rawhide' would point to rawhide. If you installed fedora-release from rawhide it would keep you on rawhide, if you install from branched or distro-sync to the branched fedora-release (by doing a 'dnf --releasever=29 distro-sync fedora-release') you go on branched. This means you don't need to worry about fedora-release-rawhide and enabling/disabling repos, and makes everyone's life easier. 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/message/VVELN7R5O6FA2NVITNNTEF356H4E223I/
Re: Making Fedora secure - Package exit policy for security
On 08/01/2018 01:46 AM, Daniel P. Berrangé wrote: > The list of ImageMagick CVEs is horrific - 59 open CVEs - for something > that is often going to be used in a scenario where it is fed untrustworthy > images. exiv2 is pretty concerning too with 19 open CVEs, again for > something often used with untrustworthy input images :-( Yeah, but this is a good example. I haven't looked at the current crop, but I did an update for ImageMagick a while back that fixed a gigantic ton of CVE's. On looking at them however, they were almost all filed from someone running a fuzzer over the source. Upstream then fixed the issues which is great, but in many cases they noted it was very hard/impossible to make an expolit out of them for various reasons. So, just seeing 59 CVE's doesn't tell the whole story. I'm not sure what the answer is here, I'm pretty sure there's no one simple answer. Perhaps a combo of concentrating on the important ones and making things more visible (generate a list of the important ones asking for help once a cycle?). 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/message/GGFEGN3KP4AK6O7PFEK3XKM4Q23AIGSH/
[EPEL-devel] Re: Getting package into stable
On 08/02/2018 08:43 AM, Richard Grainger wrote: > This package has been in testing for a month: > https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-69e2ee28b8 > > Can anyone push it to stable? Looks like it has been now. :) kevin signature.asc Description: OpenPGP digital 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/message/CW6SMLCY243PXSOEMEYOX4DY5P5GNX6A/
Re: Golang SIG for Fedora
On Thu, Aug 02, 2018 at 02:45:54PM -0500, Michael Cronenworth wrote: > On 07/27/2018 08:28 AM, Jakub Cajka wrote: > >There are few big outstanding issues that needs to be solved that need > > more than individual work, most notably the Go packaging guidelines and > > tooling. I think that should be one of the first tasks for the SIG. > > I'm not looking to join the SIG, but I will share my experience with golang > in Fedora. > > It appears that packages are being dumped into Fedora and forgotten about. > I'm trying to package "Packer"[1] and ran into multiple dependencies that > were committed once and never updated. This has to change. In my experience, the tough parts about these dependencies that got forgot about are: 1) they are only dependencies, nobody uses them for anything else; 2) many of them are not versioned upstream (we just have references to commits) 3) different applications that depend on them may need different revisions of them. while solving 3 is part of our duty as packagers (making sure to port the dependencies to use the latest versions of their dependencies), 2 seems to be quite common in the golang community... -- Athos Ribeiro http://www.ime.usp.br/~athoscr ___ 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/message/AID5NXKVSVTU55E4GRUK6LE2XZRL5YPL/
Re: Golang SIG for Fedora
On 08/02/2018 12:45 PM, Michael Cronenworth wrote: > On 07/27/2018 08:28 AM, Jakub Cajka wrote: >> There are few big outstanding issues that needs to be solved that >> need more than individual work, most notably the Go packaging >> guidelines and tooling. I think that should be one of the first tasks >> for the SIG. > > I'm not looking to join the SIG, but I will share my experience with > golang in Fedora. > > It appears that packages are being dumped into Fedora and forgotten > about. I'm trying to package "Packer"[1] and ran into multiple > dependencies that were committed once and never updated. This has to > change. > > Thanks, > Michael > > [1] https://www.packer.io/ > [2] golang-github-fatih-color > [3] golang-github-mitchellh-cli > ___ > 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/message/DSPU7L6JVKVM544M464QCAGDBGTEIONE/ A bit late to reply to this list, but I would like to be included in this SIG. ___ 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/message/V4DL63CWKRFQ6L2PBZFMM2YPSZTQNQOE/
Re: Golang SIG for Fedora
On 07/27/2018 08:28 AM, Jakub Cajka wrote: There are few big outstanding issues that needs to be solved that need more than individual work, most notably the Go packaging guidelines and tooling. I think that should be one of the first tasks for the SIG. I'm not looking to join the SIG, but I will share my experience with golang in Fedora. It appears that packages are being dumped into Fedora and forgotten about. I'm trying to package "Packer"[1] and ran into multiple dependencies that were committed once and never updated. This has to change. Thanks, Michael [1] https://www.packer.io/ [2] golang-github-fatih-color [3] golang-github-mitchellh-cli ___ 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/message/DSPU7L6JVKVM544M464QCAGDBGTEIONE/
Fedora Rawhide-20180802.n.0 compose check report
No missing expected images. Failed openQA tests: 49/138 (x86_64), 1/24 (i386), 1/2 (arm) New failures (same test did not fail in Rawhide-20180801.n.0): ID: 262899 Test: x86_64 Server-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/262899 ID: 262901 Test: x86_64 Server-dvd-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/262901 ID: 262917 Test: x86_64 Server-dvd-iso realmd_join_cockpit URL: https://openqa.fedoraproject.org/tests/262917 ID: 262918 Test: x86_64 Server-dvd-iso realmd_join_sssd URL: https://openqa.fedoraproject.org/tests/262918 ID: 262924 Test: x86_64 Everything-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/262924 ID: 262940 Test: x86_64 Workstation-boot-iso memory_check@uefi URL: https://openqa.fedoraproject.org/tests/262940 ID: 262941 Test: x86_64 Workstation-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/262941 ID: 262946 Test: x86_64 KDE-live-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/262946 ID: 262953 Test: x86_64 KDE-live-iso desktop_update_graphical URL: https://openqa.fedoraproject.org/tests/262953 ID: 262957 Test: x86_64 KDE-live-iso desktop_notifications_postinstall URL: https://openqa.fedoraproject.org/tests/262957 ID: 262964 Test: x86_64 AtomicWorkstation-dvd_ostree-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/262964 ID: 262976 Test: x86_64 universal install_no_swap@uefi URL: https://openqa.fedoraproject.org/tests/262976 ID: 262987 Test: x86_64 universal install_blivet_ext3@uefi URL: https://openqa.fedoraproject.org/tests/262987 ID: 262996 Test: x86_64 universal install_delete_pata@uefi URL: https://openqa.fedoraproject.org/tests/262996 ID: 263003 Test: x86_64 universal install_multi_empty@uefi URL: https://openqa.fedoraproject.org/tests/263003 ID: 263006 Test: x86_64 universal install_btrfs@uefi URL: https://openqa.fedoraproject.org/tests/263006 ID: 263007 Test: x86_64 universal install_ext3@uefi URL: https://openqa.fedoraproject.org/tests/263007 ID: 263009 Test: x86_64 universal install_lvmthin@uefi URL: https://openqa.fedoraproject.org/tests/263009 ID: 263022 Test: x86_64 universal install_simple_free_space@uefi URL: https://openqa.fedoraproject.org/tests/263022 ID: 263036 Test: x86_64 universal install_blivet_btrfs@uefi URL: https://openqa.fedoraproject.org/tests/263036 ID: 263037 Test: x86_64 universal install_blivet_no_swap@uefi URL: https://openqa.fedoraproject.org/tests/263037 ID: 263038 Test: x86_64 universal install_blivet_xfs@uefi URL: https://openqa.fedoraproject.org/tests/263038 ID: 263040 Test: x86_64 universal install_blivet_lvmthin@uefi URL: https://openqa.fedoraproject.org/tests/263040 Old failures (same test failed in Rawhide-20180801.n.0): ID: 262898 Test: x86_64 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/262898 ID: 262923 Test: x86_64 Everything-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/262923 ID: 262926 Test: x86_64 Workstation-live-iso install_default_upload URL: https://openqa.fedoraproject.org/tests/262926 ID: 262936 Test: x86_64 Workstation-live-iso desktop_notifications_live URL: https://openqa.fedoraproject.org/tests/262936 ID: 262938 Test: x86_64 Workstation-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/262938 ID: 262947 Test: x86_64 KDE-live-iso install_no_user URL: https://openqa.fedoraproject.org/tests/262947 ID: 262959 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/262959 ID: 262961 Test: x86_64 AtomicHost-dvd_ostree-iso install_default URL: https://openqa.fedoraproject.org/tests/262961 ID: 262971 Test: x86_64 AtomicWorkstation-dvd_ostree-iso desktop_browser URL: https://openqa.fedoraproject.org/tests/262971 ID: 262972 Test: x86_64 universal install_xfs URL: https://openqa.fedoraproject.org/tests/262972 ID: 262975 Test: x86_64 universal install_blivet_ext3 URL: https://openqa.fedoraproject.org/tests/262975 ID: 262982 Test: x86_64 universal upgrade_2_kde_64bit URL: https://openqa.fedoraproject.org/tests/262982 ID: 262983 Test: x86_64 universal upgrade_2_desktop_encrypted_64bit URL: https://openqa.fedoraproject.org/tests/262983 ID: 262984 Test: x86_64 universal install_updates_img_local URL: https://openqa.fedoraproject.org/tests/262984 ID: 262988 Test: x86_64 universal install_kickstart_firewall_configured URL: https://openqa.fedoraproject.org/tests/262988 ID: 262990 Test: x86_64 universal install_anaconda_text URL: https://openqa.fedoraproject.org/tests/262990 ID: 262991 Test: x86_64 universal install_repository_http_variation URL: https://openqa.fedoraproject.org/tests/262991 ID: 262992 Test: x86_64 universal install_package_set_kde URL:
Fedora testing-20180802.0 compose check report
No missing expected images. Passed openQA tests: 2/2 (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://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/message/LI4MJ5RODJMNHHVOAXP6QMDSLSWX7HYF/
Fedora updates-20180802.0 compose check report
No missing expected images. Passed openQA tests: 2/2 (x86_64) Installed system changes in test x86_64 AtomicHost-dvd_ostree-iso install_default: System load changed from 0.28 to 0.44 Previous test data: https://openqa.fedoraproject.org/tests/262638#downloads Current test data: https://openqa.fedoraproject.org/tests/263086#downloads -- 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/message/6ROIM4OF3NAMGVQRZCT3RTD4NDC5EUMJ/
Fedora rawhide compose report: 20180802.n.0 changes
OLD: Fedora-Rawhide-20180801.n.0 NEW: Fedora-Rawhide-20180802.n.0 = SUMMARY = Added images:6 Dropped images: 2 Added packages: 4 Dropped packages:0 Upgraded packages: 115 Downgraded packages: 1 Size of added packages: 321.33 KiB Size of dropped packages:0 B Size of upgraded packages: 5.10 GiB Size of downgraded packages: 34.97 MiB Size change of upgraded packages: -129.86 MiB Size change of downgraded packages: 6.57 KiB = ADDED IMAGES = Image: Design_suite live x86_64 Path: Labs/x86_64/iso/Fedora-Design_suite-Live-x86_64-Rawhide-20180802.n.0.iso Image: Container_Minimal_Base docker s390x Path: Container/s390x/images/Fedora-Container-Minimal-Base-Rawhide-20180802.n.0.s390x.tar.xz Image: Python_Classroom vagrant-virtualbox i386 Path: Labs/i386/images/Fedora-Python-Classroom-Vagrant-Rawhide-20180802.n.0.i386.vagrant-virtualbox.box Image: Design_suite live i386 Path: Labs/i386/iso/Fedora-Design_suite-Live-i386-Rawhide-20180802.n.0.iso Image: Container_Base docker ppc64le Path: Container/ppc64le/images/Fedora-Container-Base-Rawhide-20180802.n.0.ppc64le.tar.xz Image: Python_Classroom vagrant-libvirt i386 Path: Labs/i386/images/Fedora-Python-Classroom-Vagrant-Rawhide-20180802.n.0.i386.vagrant-libvirt.box = DROPPED IMAGES = Image: AtomicHost raw-xz ppc64le Path: AtomicHost/ppc64le/images/Fedora-AtomicHost-Rawhide-20180801.n.0.ppc64le.raw.xz Image: AtomicHost qcow2 ppc64le Path: AtomicHost/ppc64le/images/Fedora-AtomicHost-Rawhide-20180801.n.0.ppc64le.qcow2 = ADDED PACKAGES = Package: perl-Monkey-Patch-0.03-1.fc29 Summary: Scoped monkey-patching Perl module RPMs:perl-Monkey-Patch Size:24.69 KiB Package: perl-Sub-Delete-1.2-1.fc29 Summary: Perl module to delete subroutines RPMs:perl-Sub-Delete Size:12.70 KiB Package: python-feedgenerator-1.9-6.fc29 Summary: Standalone version of Django's feedgenerator module RPMs:python2-feedgenerator python3-feedgenerator Size:83.55 KiB Package: wpebackend-0.2.0-1.fc29 Summary: General-purpose library specifically developed for the WPE-flavored port of WebKit. RPMs:wpebackend wpebackend-devel Size:200.39 KiB = DROPPED PACKAGES = = UPGRADED PACKAGES = Package: COPASI-4.24.197-1.fc29 Old package: COPASI-4.23.184-15.fc29 Summary: Biochemical network simulator RPMs: COPASI COPASI-data COPASI-doc COPASI-gui COPASI-sharp R-COPASI perl-COPASI python3-COPASI Dropped RPMs: python2-COPASI Size: 196.96 MiB Size change: -31.62 MiB Changelog: * Tue Jul 31 2018 Antonio Trande - 4.24.197-1 - Release 4.24 build-187 - Erase obsolete patches - Drop Python2 binding - Disable BUILD_CXX_EXAMPLES Package: awscli-1.15.69-1.fc29 Old package: awscli-1.15.66-1.fc29 Summary: Universal Command Line Environment for AWS RPMs: awscli Size: 1.07 MiB Size change: -6.59 KiB Changelog: * Wed Aug 01 2018 Kevin Fenzi - 1.15.69-1 - Update to 1.15.69. Fixes bug #1610059 Package: ccnet-6.1.8-1.fc29 Old package: ccnet-6.1.6-2.fc29 Summary: A framework for writing networked applications in C RPMs: ccnet ccnet-devel Size: 1.19 MiB Size change: -73.76 KiB Changelog: * Wed Aug 01 2018 Julien Enselme - 6.1.8-1 - Update to 6.1.8 Package: clover2-4.7.8-1.D20180801git66fdbac.fc29 Old package: clover2-4.7.2-1.D20180723gita3db523.fc29 Summary: Yet another compiler language RPMs: clover2 clover2-devel clover2-libs Size: 5.85 MiB Size change: -23.40 KiB Changelog: * Wed Aug 01 2018 Mamoru TASAKA - 4.7.8-1.D20180801git66fdbac - 4.7.8 Package: clusterPy-0.9.9-17.fc29 Old package: clusterPy-0.9.9-16.fc28 Summary: Library of spatially constrained clustering algorithms RPMs: clusterPy Size: 132.59 KiB Size change: -1.37 KiB Changelog: * Thu Jul 12 2018 Fedora Release Engineering - 0.9.9-17 - Rebuilt for https://fedoraproject.org/wiki/Fedora_29_Mass_Rebuild Package: cockpit-174-1.fc29 Old package: cockpit-173-3.fc29 Summary: A user interface for Linux servers RPMs: cockpit cockpit-bridge cockpit-dashboard cockpit-doc cockpit-docker cockpit-kdump cockpit-kubernetes cockpit-machines cockpit-machines-ovirt cockpit-networkmanager cockpit-ostree cockpit-packagekit cockpit-pcp cockpit-selinux cockpit-sosreport cockpit-storaged cockpit-system cockpit-tests cockpit-ws Size: 39.25 MiB Size change: 51.50 KiB Changelog: * Wed Aug 01 2018 Marius Vollmer - 174-1 - Kubernetes: VM detail page - Realmd: Install on demand Package: comic-neue-fonts-2.3-1.fc29 Old package: comic-neue-fonts-2.2-7.fc29 Summary: A typeface family inspired by Comic Sans RPMs: comic-neue-angular-fonts comic-neue-fonts comic-neue-fonts-common Size: 584.03 KiB Size change: 35.16 KiB Changelog: * Wed Aug 01 2018 Karel Voln?? 2.3-1 - new version 2.3 (#1376999) - added support for Esperanto
[EPEL-devel] Fedora EPEL 6 updates-testing report
The following Fedora EPEL 6 Security updates need testing: Age URL 53 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-b6c663378c unrtf-0.21.9-8.el6 21 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-d801e05f92 uwsgi-2.0.17.1-1.el6 14 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-aeb81e4fba libpng10-1.0.69-5.el6 12 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-a83d5ad82b redis-3.2.12-1.el6 11 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-b4f8d828cd perl-Parallel-ForkManager-1.20-1.el6 9 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-68e2f541df pam_yubico-2.26-1.el6 4 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-4186e02757 seamonkey-2.49.4-2.el6 The following builds have been pushed to Fedora EPEL 6 updates-testing inxi-3.0.20-1.el6 Details about builds: inxi-3.0.20-1.el6 (FEDORA-EPEL-2018-c1c72c615e) A full featured system information script Update Information: Update to 3.0.20. ChangeLog: * Wed Aug 1 2018 Vasiliy N. Glazov 3.0.20-1 - Update to 3.0.18 * Thu Jul 19 2018 Vasiliy N. Glazov 3.0.18-1 - Update to 3.0.18 ___ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/message/IAAUQQERXBPXP3AQOVIVVMFOUVKO4ULT/
Re: F29 System Wide Change: Remove Excessive Linking
The real problem here is when you have complex frameworks like gtk. pkg-config basically will link you against gdk, gdk-pixbuf, gtk and a lot of other stuff. But in practice, not every application need to link against all of them. On Thu, Aug 2, 2018 at 6:11 PM Rex Dieter wrote: > Dominique Martinet wrote: > > > In practice, `pkg-config --cflags foo` will only fetch cflags for > > dependencies listed in Requires, not Requires.private > > pkg-config --cflags foo > fetches cflags of Requires.private items in foo.pc for me. > > I've patched many packages to use that feature, and haven't noticed any > breakage (so far). > > -- 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/message/L3Y3PPOF33WNTZBGO64YKJARAQSC3O7Q/ > -- -Igor Gnatenko ___ 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/message/HREOSWQIASKMKVWVLV6GJAID3MBIRHUC/
[EPEL-devel] Getting package into stable
This package has been in testing for a month: https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-69e2ee28b8 Can anyone push it to stable? Thanks! ___ 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://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/epel-devel@lists.fedoraproject.org/message/Z6J3UZ6IG4WUI3ZR2JFVIUCX7MH4F5G7/
Re: F29 System Wide Change: Remove Excessive Linking
Dominique Martinet wrote: > In practice, `pkg-config --cflags foo` will only fetch cflags for > dependencies listed in Requires, not Requires.private pkg-config --cflags foo fetches cflags of Requires.private items in foo.pc for me. I've patched many packages to use that feature, and haven't noticed any breakage (so far). -- 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/message/L3Y3PPOF33WNTZBGO64YKJARAQSC3O7Q/
[Bug 857802] perl-Tk missing /usr/bin/widget
https://bugzilla.redhat.com/show_bug.cgi?id=857802 --- Comment #2 from Xavier Bachelot --- widget is actually installed in the doc directory. /usr/share/doc/perl-Tk-804.028/widget -- 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/message/QKH4HMP5X765V5F7MGVPWYMAVFP5B3BO/
[Bug 857802] perl-Tk missing /usr/bin/widget
https://bugzilla.redhat.com/show_bug.cgi?id=857802 Xavier Bachelot changed: What|Removed |Added CC||andreas.bierfert@lowlatency ||.de Component|perl-Tk |perl-Tk Version|el6 |rawhide Product|Fedora EPEL |Fedora --- Comment #1 from Xavier Bachelot --- I'm not sure why /usr/bin/widget is specifically excluded. Maybe there is a reason I'm missing. This is like that since initial import (014fee7), so reassigning to Fedora Rawhide, as it has the same issue. -- 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/message/ZCVXHSLYB4GTGM2ICUSU35EENDNZWMGI/
Re: F29 System Wide Change: Remove Excessive Linking
Rex Dieter wrote on Thu, Aug 02, 2018 at 08:37:34AM -0500: > > Wearing a lib developer hat, I don't see how you can make a .pc that > > doesn't overlink if you provide something a bit entangled with other > > libs. > > The problem is that if your headers use any sub-lib type you need to add > > that lib in Requires: so that --cflags will pull that lib's include > > path; > > That's what Requires.private is for I'm aware of Requires.private, but that's not how I understand things currently work. man pc(5) says this for Requires and Requires.private: --- Requires Required dependencies that must be met for the package to be usable. All dependencies must be satisfied or the pkg-config implementation must not use the package. (optional; dependency list) Requires.private Required dependencies that must be met for the package to be usable for static linking. All dependencies must be satisfied or the pkg-config implementation must not use the package for static linking. (optional; dependency list) --- I'm not sure I see how that would be related to what is used for compiling and what is used for linking. In practice, `pkg-config --cflags foo` will only fetch cflags for dependencies listed in Requires, not Requires.private I haven't tested how autotools/libtool handle this but I doubt it's much different than invoking pkg-config manually, and at least meson will only add cflags for dependencies put in 'Requires' as I would have expected. Am I missing something? -- Dominique Martinet ___ 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/message/ULSIOZQG7E2RBY2OOEXPAPSCAZINRTUM/
Re: F29 System Wide Change: Remove Excessive Linking
Dominique Martinet wrote: > Karel Zak wrote on Wed, Aug 01, 2018 at 01:17:29PM +0200: >> Well, --as-needed is workaround and nothing else. The real problem is >> mess in makefiles and .pc (pkg-config) files. >> >> It would be better to use --as-needed for testing purpose only, and >> ask maintainers why the result with --as-needed is different. > > Wearing a lib developer hat, I don't see how you can make a .pc that > doesn't overlink if you provide something a bit entangled with other > libs. > The problem is that if your headers use any sub-lib type you need to add > that lib in Requires: so that --cflags will pull that lib's include > path; That's what Requires.private is for -- 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/message/BRI4JJWM5BOM2IH24EUFYYGADRZNIBXX/
Re: Making Fedora secure - Package exit policy for security
On Thu, 2018-08-02 at 10:49 +0100, Daniel P. Berrangé wrote: > > > > > > Thank you Huzaifa for bringing that up. I have a talk on fedora > > > and > > > crypto in flock, and my recommendation will be towards having > > > some > > > process to remove old packages from fedora. CVEs were not the > > > drivers > > > there, but the continuous expansion of the crypto core which at > > > the end > > > as you say causes CVEs which no-one addresses. To add to that, we > > > ship > > > several packages which are the result of an internship, thesis, > > > packages which are there just in case and all expand the attack > > > surface. > > > > > > So yes, I'd support something like that, and even further than > > > that, if > > > there is no update (upstream release) for 5 years, the > > > package+dependencies is marked for removal as well. Cancelling > > > that > > > process would have to go through a fedora committee. > > > > > > > Thank you very much for supporting me on this. This proposal has > > come > > after years of experience in dealing with Security in Red Hat, > > upstream > > and Fedora itself. Honestly the volume of pkgs in Fedora is > > disturbing, > > more disturbing are fly-by maintainers, who do packaging for > > university > > projects etc and then disappear :( > > The majority of stuff on the big list of CVEs looks like mainstream > software, that has been present in Fedora for a long time, with long > term maintainers. The kind of packages added as side-effect of > academic > projects by fly-by maintainers are likely fairly niche use cases, or > they would have been already added to Fedora. IOW, I don't think fly- > by > maintainers are the big problem in our CVE/security handling story > here. It makes sense but I don't entirely agree. Indeed for these cases we do not have CVEs because most likely no-one is checking these special use cases. We have several insecure crypto libs, several apps that implement their own crypto that would surprise most of us. So my point is that reducing vulnerabilities is the goal here, and CVEs is only one metric of them. regards, Nikos ___ 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/message/HVQ25MPBKWQ2KAS5VCBVZUW533ARVQDZ/
[Bug 1611585] New: perl-Log-Any-1.707 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1611585 Bug ID: 1611585 Summary: perl-Log-Any-1.707 is available Product: Fedora Version: rawhide Component: perl-Log-Any Keywords: FutureFeature, Triaged Assignee: ticot...@gmail.com Reporter: upstream-release-monitor...@fedoraproject.org QA Contact: extras...@fedoraproject.org CC: perl-devel@lists.fedoraproject.org, st...@silug.org, ticot...@gmail.com, xav...@bachelot.org Latest upstream release: 1.707 Current version/release in rawhide: 1.706-2.fc29 URL: http://search.cpan.org/dist/Log-Any/ 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/6480/ -- 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/message/3YJJ5IXOBMO3H3O2WBDQ4TFQ7WFMOYIK/
Re: RFC: make $releasever return "rawhide" on Rawhide
On Thu, Aug 2, 2018 at 2:07 PM Neal Gompa wrote: > On Tue, Jul 31, 2018 at 9:59 AM Kamil Paral wrote: > > > > Hello devel list, > > > > this is a request for comments for a recent proposal I filed at releng > tracker: > > https://pagure.io/releng/issue/7445 > > > > In short, package managers on Rawhide would no longer replace > $releasever variable with a numerical value (like '29' at this moment, soon > '30'), but with 'rawhide' string instead. I hope this change will make life > a bit easier for third-party repos maintainers, for users, for developers > and sysadmins, and for release engineering. The technical implementation > can be seen in the ticket (it's the 'Proposed solution 1'), together with a > long discussion. > > > > To provide a longer explanation of the improvements I expect this to > bring: > > * Third-party repo maintainers will no longer need to provide two > different repo files, one for stable Fedora releases using $releasever in > URLs, and one for Rawhide hardcoding 'rawhide/' in URL and avoiding > $releasever in URL. (Technically, two repo files are not needed if you > always use a numbered dir even for Rawhide, but that's maintenance-heavy, > because you need to change the directory number precisely at Branching > time). This involves COPR as well. > > * Users will be able to run commands like "dnf ... --releasever=28" even > on Rawhide. That doesn't work at the moment, because most repo files don't > use $releasever and instead have 'rawhide/' hardcoded. > > * Developers and sysadmins will be able to use the same approach > regarding repositories for stable Fedora releases and Rawhide. Rawhide will > no longer be different, requiring special treatment. For example, the same > repo URL can be used to install a system, or the same URL can be used to > add an additional repository to an existing system. As an engineer working > on automation, I was always annoyed how I need to special-case Rawhide > everywhere (and of course, maintain a config file that states which release > number Rawhide currently maps to). That will hopefully be no longer > necessary, or very much reduced. > > * Fedora release engineers should be able to get rid of > fedora-repos-rawhide (again, hardcoding 'rawhide/' in URL), and use the > standard repo files instead (making use of $releasever). > > > > There might be other advantages, which I haven't tested or though of. > > > > There are also disadvantages. The only one I know of at this moment, is > that PackageKit is currently incompatible with this change (it uses custom > logic for populating $releasever, different from dnf logic) and will need > adjustments. > > > > Fedora releng has pre-approved this change in the ticket, and the point > of this email is to ask for more feedback from all of you. I'd appreciate > if you could help us identify edge cases we haven't thought of, or point > out which tools would be incompatible with this change, so that we can > track them and discuss it with their developers. > > > > This might surprise you, but I actually prefer the current way. It > makes activating Rawhide an explicit action that can stay carried > forward. The other thing is, realistically, few third party folks try > to build for Rawhide because Rawhide snapshots are either too old or > too broken. > > Case in point, the Docker containers for Rawhide effectively look like > Fedora 28, so what's the point? And upgrading to the latest released > compose just breaks everything, so it's not useful there either. > > This change makes no sense unless we were actually going to make > Rawhide something that people could rely on. And I'm not sure that's a > good idea, since we have a nice cadence of releasing every 6 > months(-ish). It's already too hard to keep Rawhide working because of > GCC breakages and the DNF stack work, and upstreams rely on our > Rawhide tree to suss out these kinds of things. > If we can make rawhide something that people can rely on, the actual releases will benefit from it as well. > > And I would argue that special casing Rawhide is sort of the point, > but I have no objection to making dnf --releasever=rawhide distro-sync > also work. I just don't think it's smart to drop the release number > thing and the fedora-repos-rawhide package. > > > > -- > 真実はいつも一つ！/ Always, there's only one truth! > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: https://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/message/XGMTZTWR2QYDNSCONEPS4RR567DELMDT/ > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct:
Re: RFC: make $releasever return "rawhide" on Rawhide
On Tue, Jul 31, 2018 at 9:59 AM Kamil Paral wrote: > > Hello devel list, > > this is a request for comments for a recent proposal I filed at releng > tracker: > https://pagure.io/releng/issue/7445 > > In short, package managers on Rawhide would no longer replace $releasever > variable with a numerical value (like '29' at this moment, soon '30'), but > with 'rawhide' string instead. I hope this change will make life a bit easier > for third-party repos maintainers, for users, for developers and sysadmins, > and for release engineering. The technical implementation can be seen in the > ticket (it's the 'Proposed solution 1'), together with a long discussion. > > To provide a longer explanation of the improvements I expect this to bring: > * Third-party repo maintainers will no longer need to provide two different > repo files, one for stable Fedora releases using $releasever in URLs, and one > for Rawhide hardcoding 'rawhide/' in URL and avoiding $releasever in URL. > (Technically, two repo files are not needed if you always use a numbered dir > even for Rawhide, but that's maintenance-heavy, because you need to change > the directory number precisely at Branching time). This involves COPR as well. > * Users will be able to run commands like "dnf ... --releasever=28" even on > Rawhide. That doesn't work at the moment, because most repo files don't use > $releasever and instead have 'rawhide/' hardcoded. > * Developers and sysadmins will be able to use the same approach regarding > repositories for stable Fedora releases and Rawhide. Rawhide will no longer > be different, requiring special treatment. For example, the same repo URL can > be used to install a system, or the same URL can be used to add an additional > repository to an existing system. As an engineer working on automation, I was > always annoyed how I need to special-case Rawhide everywhere (and of course, > maintain a config file that states which release number Rawhide currently > maps to). That will hopefully be no longer necessary, or very much reduced. > * Fedora release engineers should be able to get rid of fedora-repos-rawhide > (again, hardcoding 'rawhide/' in URL), and use the standard repo files > instead (making use of $releasever). > > There might be other advantages, which I haven't tested or though of. > > There are also disadvantages. The only one I know of at this moment, is that > PackageKit is currently incompatible with this change (it uses custom logic > for populating $releasever, different from dnf logic) and will need > adjustments. > > Fedora releng has pre-approved this change in the ticket, and the point of > this email is to ask for more feedback from all of you. I'd appreciate if you > could help us identify edge cases we haven't thought of, or point out which > tools would be incompatible with this change, so that we can track them and > discuss it with their developers. > This might surprise you, but I actually prefer the current way. It makes activating Rawhide an explicit action that can stay carried forward. The other thing is, realistically, few third party folks try to build for Rawhide because Rawhide snapshots are either too old or too broken. Case in point, the Docker containers for Rawhide effectively look like Fedora 28, so what's the point? And upgrading to the latest released compose just breaks everything, so it's not useful there either. This change makes no sense unless we were actually going to make Rawhide something that people could rely on. And I'm not sure that's a good idea, since we have a nice cadence of releasing every 6 months(-ish). It's already too hard to keep Rawhide working because of GCC breakages and the DNF stack work, and upstreams rely on our Rawhide tree to suss out these kinds of things. And I would argue that special casing Rawhide is sort of the point, but I have no objection to making dnf --releasever=rawhide distro-sync also work. I just don't think it's smart to drop the release number thing and the fedora-repos-rawhide package. -- 真実はいつも一つ！/ Always, there's only one truth! ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://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/message/XGMTZTWR2QYDNSCONEPS4RR567DELMDT/
[Bug 1611024] perl-DateTime-1.50 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1611024 Paul Howarth changed: What|Removed |Added Status|NEW |CLOSED Fixed In Version||perl-DateTime-1.50-1.fc29 Resolution|--- |RAWHIDE Last Closed||2018-08-02 06:39:07 --- Comment #1 from Paul Howarth --- Build done: https://koji.fedoraproject.org/koji/taskinfo?taskID=28784653 -- 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/message/PYHTGQKUJ5CA24VDRN3VWTNEF4EDNZZX/
Re: RFC: make $releasever return "rawhide" on Rawhide
Dne 31.7.2018 v 15:04 Kamil Paral napsal(a): > In short, package managers on Rawhide would no longer replace $releasever > variable with a numerical value (like '29' at > this moment, soon '30'), but with 'rawhide' string instead. I hope this > change will make life a bit easier for > third-party repos maintainers, for users, for developers and sysadmins, and > for release engineering. The technical > implementation can be seen in the ticket (it's the 'Proposed solution 1'), > together with a long discussion. Just note that fedora-rawhide.repo has: gpgkey=file:///etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-$releasever-$basearch Which now points to /etc/pki/rpm-gpg/RPM-GPG-KEY-fedora-29-x86_64 (on x86_64 machine). So either this file need to be renamed to RPM-GPG-KEY-fedora-rawhide-x86_64 and updated on every branching or symlink need to be provided. Miroslav ___ 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/message/U6TACYNXEINUFHGNHIHGPAZRM2Q5J6CD/
Re: Making Fedora secure - Package exit policy for security
On Thu, Aug 02, 2018 at 01:54:21PM +0530, Huzaifa Sidhpurwala wrote: > On 08/01/2018 02:16 PM, Daniel P. Berrangé wrote: > > On Wed, Aug 01, 2018 at 10:40:20AM +0530, Huzaifa Sidhpurwala wrote: > >> On 07/31/2018 08:51 PM, Daniel P. Berrangé wrote: > >>> Then, from that list of packages, do we have idea of reasons why > >>> their CVEs are not getting fixed in Fedora. This could perhaps identify > >>> changes to help with the problem(s), rather than jumping straight to > >>> the big stick of dropping packages. > >> > >> I definitely want to address the core problem here, but i dont want to > >> go through tens and even sometimes hundreds of bugs to figure out why > >> they have not been fixed. Shouldnt the package maintainer be doing it in > >> the first place? > > > > Obviously the responsibility lies with the package maintainer, but look > > at what Fedora says their responsibility is: > > > > https://fedoraproject.org/wiki/Package_maintainer_responsibilities > > > > [quote] > > Manage security issues > > > > Package maintainer should handle security issues quickly, and if they > > need help they should contact the Security Response Team. > > [/quote] > > > > The bugs we file against packages have big boilerplate text, but that's > > focused around the mechanics of submitting updates, and again doesn't > > give any guidance on how effectively triage the security bugs. > > > Those bugs are linked against "CVE bugs" which are filed against > product-security component. The "CVE bugs" contain details, including > patches, reproducers, upstream links etc. Sure, that's helpful once you've decided to try to address the problem, but I was talking about the step before that. As a maintainer there is almost always more work needing attention, than there is free time in the day. Understanding expectations around how quickly bugs need addressing is a key factor here. > > Some maintainers are lucky enough to have experience of dealing with CVEs > > from RHEL work, but many/most are not. The reality is much more nuanced > > than "should handle security issues quickly". IMPORTANT and CRITICAL rated > > security bugs must be handled on very different timeframe from LOW rated > > bugs. The latter would be valid to just wait for a rebase in future Fedora > > major release and mark CLOSED->UPSTREAM, while the former is something > > you'd want to urgently backport fixes for into all existing releases. > > MODERATE bugs get into a grey area where its hard to give a clear rule, > > as urgency to fix them varies depending on usage context of the package. > > > In any case, putting a comment on the bug, with details like "No patch", > "i am working on this one", or even "rebased in FEdora28, wont fix in > f26" is fine! > > > So I can't put all blame on the package maintainers for failing to deal > > with CVEs appropriately, when we're setting them up to fail by giving > > little-to-no guidance on what's really expected in this area. > > > Shouldnt they ask for guidance then? I am happy to write docs/FAQs if > there are any questions/comments. Again it is a matter of time. Understand that maintaniers are usually overworked and so look for the minimal effort path. Given a pile of new bugs they'll skim through the bug description and pick tasks to attack based on some tradeoff between what looks most urgent vs time effective to fix. From this point of view it is more time effective if we provide clear guidance on expectations around security bugs upfront, rather than expecting to resort to asking for guidance via email. Asking for guidance should be the exception. > > That's obviously not the entire story here though - even with better docs, > > I'm confident we'd still have a significant problem to consider. Some of > > this may well be a result of maintainers simply having too many packages > > to deal with. With the traditional "single owner" model of Fedora package > > maint there's a tendancy to leave the fixing to the officially assigned > > owner. For packages that we see a high volume of CVEs against, we perhaps > > need to work ensure there are multiple maintainers recorded against the > > package to give some redundancy. > > > How to do that? ie convince people to co-maintain pkgs with high CVE > loads? given that cves are deterrent to pkg maintainers! "High CVE loads" is usually just a small part of the bigger "high bug loads" pictures, which is usually a result of it being a very popular/mainstrema app. Fedora has set special policies for subsets of packages in the past, such as the rules around issuing updates for critical path packages. It is not unreasonable to identify some set of 'security critical packages' and declare that those must have multiple assigned owners and more stringent expectations around response time for CVEs. Fedora has traditionally had a fairly strong 'single owner' oriented mindset of package maint, but its often been clear that this has downsides, very often due to the
Re: F29 System Wide Change: Remove Excessive Linking
On Thu, Aug 02, 2018 at 11:45:00AM +0200, Dominique Martinet wrote: > Wearing a lib developer hat, I don't see how you can make a .pc that > doesn't overlink if you provide something a bit entangled with other > libs. > The problem is that if your headers use any sub-lib type you need to add > that lib in Requires: so that --cflags will pull that lib's include > path; and that will in turn add that sub-lib to the linked libs even if > the program likely doesn't care about it (either because they didn't > even use that part of your lib, or because all uses of that lib will be > done through your own anyway so it wasn't required in the first place) Then it is clearly a task for pkg-config (and libtool) to handle it better. If the --libs it provides contains some mandatory and some optionally needed libraries, then it should differentiate between them and use -Wl,--push-state,--as-needed ... -Wl,--pop-state around those that are optionally needed. If all libraries from those tools are optional, perhaps it should use it always. Changing the behavior of say -lpthread on the command line is a bad idea, many projects really expect it to mean that the mentioned library is linked in and if it no longer does, it causes silent breakage. Forcing users to do -Wl,--push-state,--no-as-needed ... -Wl,--pop-state whenever they really mean to link some library is too hostile. Jakub ___ 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/message/JPGEVUGN3MCK4LEQRO7JR3D6WJAQEFPJ/
Re: Making Fedora secure - Package exit policy for security
On Thu, Aug 02, 2018 at 01:49:13PM +0530, Huzaifa Sidhpurwala wrote: > On 08/01/2018 01:19 PM, Nikos Mavrogiannopoulos wrote: > > On Tue, 2018-07-31 at 09:09 +0530, Huzaifa Sidhpurwala wrote: > >> Hi All, > >> > >> I was asked to bring this issue[1] to the developer community before > >> FESCO makes a decision. > >> > >> In several instances[2] there exists packages in Fedora, in which > >> package-maintainers did not patch security issues, for multiple > >> reasons > >> including 1. non-responsive maintainer 2. issue hard to patch 3. no > >> one > >> cares? > >> > >> This is a risk for the distribution, our users and community as a > >> whole > >> and not to mentioned bad PR :) > >> > >> I would like to propose the following: > >> > >> > >> 1. If a CRITICAL or IMPORTANT security issue is open against a > >> package > >> in Fedora-X and by the time X is EOL and the issue is not addressed, > >> proactively remove the package from X+1 > >> 2. If a MODERATE or LOW security issue is open against a package in > >> Fedora -X and by the time X+! is EOL, the issue is not addressed, > >> remove > >> it from X+2 > >> > >> Note: > >> 1. Once pkg is patches, it can be rebuild and re-introduced into the > >> distro > >> 2. X/X+1 is the best boundary to remove the insecure packages imo, > >> since > >> inbetween removals are not possible due to the way mirrors work. > >> 3. Maintain a list somewhere (automated maybe) of the list of > >> packages > >> removed and why. > >> 4. Have a list of critical pkg, which cannot be removed which will > >> break > >> the distro. > >> > >> The above is not set in stone, but is open for discussion. Let me > >> know > >> what you guys think! > >> > >> In the end, i would like you leave you all with this parting link: > >> > > > > Thank you Huzaifa for bringing that up. I have a talk on fedora and > > crypto in flock, and my recommendation will be towards having some > > process to remove old packages from fedora. CVEs were not the drivers > > there, but the continuous expansion of the crypto core which at the end > > as you say causes CVEs which no-one addresses. To add to that, we ship > > several packages which are the result of an internship, thesis, > > packages which are there just in case and all expand the attack > > surface. > > > > So yes, I'd support something like that, and even further than that, if > > there is no update (upstream release) for 5 years, the > > package+dependencies is marked for removal as well. Cancelling that > > process would have to go through a fedora committee. > > > Thank you very much for supporting me on this. This proposal has come > after years of experience in dealing with Security in Red Hat, upstream > and Fedora itself. Honestly the volume of pkgs in Fedora is disturbing, > more disturbing are fly-by maintainers, who do packaging for university > projects etc and then disappear :( The majority of stuff on the big list of CVEs looks like mainstream software, that has been present in Fedora for a long time, with long term maintainers. The kind of packages added as side-effect of academic projects by fly-by maintainers are likely fairly niche use cases, or they would have been already added to Fedora. IOW, I don't think fly-by maintainers are the big problem in our CVE/security handling story here. For niche software the concern is probably the scale of unknowns. The majority of CVEs get filed against widely used / well known software because that is what attracts the attention of security researchers / bad guys. We've certainly got lots of software in Fedora with many security flaws that no one knows about because no one is looking for them, not even their upstreams. In that sense, /some/ software with lots of CVEs might be considered more secure than software with no CVEs because it demonstrates that people are actively working to understand & fix the security of that software, as opposed to ignoring the hidden problems. Regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| ___ 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/message/HEUL6HIKCDHVQK6FB47M3SIDJ5JCU3RU/
Re: F29 System Wide Change: Remove Excessive Linking
Karel Zak wrote on Wed, Aug 01, 2018 at 01:17:29PM +0200: > Well, --as-needed is workaround and nothing else. The real problem is > mess in makefiles and .pc (pkg-config) files. > > It would be better to use --as-needed for testing purpose only, and > ask maintainers why the result with --as-needed is different. Wearing a lib developer hat, I don't see how you can make a .pc that doesn't overlink if you provide something a bit entangled with other libs. The problem is that if your headers use any sub-lib type you need to add that lib in Requires: so that --cflags will pull that lib's include path; and that will in turn add that sub-lib to the linked libs even if the program likely doesn't care about it (either because they didn't even use that part of your lib, or because all uses of that lib will be done through your own anyway so it wasn't required in the first place) This isn't obvious if you only support systems like fedora where most packages include dirs are standard to /usr/include but if you want to start supporting people working with dependencies in subdirs or distros like nixos that will have one include directory per dependency, you really need to put every external headers your depend on as 'Requires'. Unless you can tell pkgconfig "take all of these dependencies for --cflags but not for --libs" I do not see how this can be improved, and that's where --as-needed is helpful. It's not the ideal solution, but I don't have anything better right now, and pkg-config is by far not the worst solution to handling dependencies... -- Dominique Martinet ___ 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/message/WD7WBZSVKQVF2KWABZGBYQFFW6EIOMGR/
Java auto-requires generator change
FPC decided [1] that Java packages must require javapckages-filesystem instead of javapackages-tools. I've just updated [2] upstream code generator code to comply with updated packaging guidelines and backported [3] the patch to rawhide. [1] https://pagure.io/packaging-committee/issue/781 [2] https://github.com/fedora-java/javapackages/pull/63 [3] https://bugzilla.redhat.com/show_bug.cgi?id=1600426 -- Mikolaj Izdebski Senior Software Engineer, Red Hat IRC: mizdebsk ___ 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/message/QNNCXRMUXTIAPOEUQJ73JLCLKV3AT4PZ/
Re: Making Fedora secure - Package exit policy for security
Nikos Mavrogiannopoulos wrote: > and even further than that, if > there is no update (upstream release) for 5 years, the > package+dependencies is marked for removal as well. Cancelling that > process would have to go through a fedora committee. It may be rare but there is such a thing as stable and mature software. It would be unfortunate if high-quality software would be kicked out just because it's not in constant flux. But if there are known security bugs and nobody is fixing them, then yes, dump that junk in a deep-sea trench! Björn Persson pgpULUbmNFVuJ.pgp Description: OpenPGP digital signatur ___ 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/message/Y6OIUKVRNZNNXJSF5KPVRJPNCRA4VYYX/
Re: Making Fedora secure - Package exit policy for security
On 08/01/2018 02:16 PM, Daniel P. Berrangé wrote: > On Wed, Aug 01, 2018 at 10:40:20AM +0530, Huzaifa Sidhpurwala wrote: >> On 07/31/2018 08:51 PM, Daniel P. Berrangé wrote: >> >>> >>> Do we have any analysis showing what would be the fallout if we applied >>> these purge rules today ? ie what packages would be dropped today due >>> to unaddressed CVEs. >>> >> See reply to my previous email. Also i have attached the list here. I >> did some random analysis and came up with the following conclusion: >> >> https://bugzilla.redhat.com/show_bug.cgi?id=1493497 >> This one is ftbs on ppc >> >> https://bugzilla.redhat.com/show_bug.cgi?id=1488785 >> This one was actually fixed, but the bug did not close >> >> https://bugzilla.redhat.com/show_bug.cgi?id=1487715 >> This is iamgemagick so one of many cves which are open against it. > > The list of ImageMagick CVEs is horrific - 59 open CVEs - for something > that is often going to be used in a scenario where it is fed untrustworthy > images. exiv2 is pretty concerning too with 19 open CVEs, again for > something often used with untrustworthy input images :-( > You havent seen ImageMagick issues yet :) I agree some of them cannot be fixed, because upstream did not fix them, but atleast there should be some mechanism or marking such pkgs as "has lot of CVEs use at your own risk". Not sure how, i havent thought about that yet. >>> Then, from that list of packages, do we have idea of reasons why >>> their CVEs are not getting fixed in Fedora. This could perhaps identify >>> changes to help with the problem(s), rather than jumping straight to >>> the big stick of dropping packages. >> >> I definitely want to address the core problem here, but i dont want to >> go through tens and even sometimes hundreds of bugs to figure out why >> they have not been fixed. Shouldnt the package maintainer be doing it in >> the first place? > > Obviously the responsibility lies with the package maintainer, but look > at what Fedora says their responsibility is: > > https://fedoraproject.org/wiki/Package_maintainer_responsibilities > > [quote] > Manage security issues > > Package maintainer should handle security issues quickly, and if they > need help they should contact the Security Response Team. > [/quote] > > The bugs we file against packages have big boilerplate text, but that's > focused around the mechanics of submitting updates, and again doesn't > give any guidance on how effectively triage the security bugs. > Those bugs are linked against "CVE bugs" which are filed against product-security component. The "CVE bugs" contain details, including patches, reproducers, upstream links etc. > Some maintainers are lucky enough to have experience of dealing with CVEs > from RHEL work, but many/most are not. The reality is much more nuanced > than "should handle security issues quickly". IMPORTANT and CRITICAL rated > security bugs must be handled on very different timeframe from LOW rated > bugs. The latter would be valid to just wait for a rebase in future Fedora > major release and mark CLOSED->UPSTREAM, while the former is something > you'd want to urgently backport fixes for into all existing releases. > MODERATE bugs get into a grey area where its hard to give a clear rule, > as urgency to fix them varies depending on usage context of the package. > In any case, putting a comment on the bug, with details like "No patch", "i am working on this one", or even "rebased in FEdora28, wont fix in f26" is fine! > So I can't put all blame on the package maintainers for failing to deal > with CVEs appropriately, when we're setting them up to fail by giving > little-to-no guidance on what's really expected in this area. > Shouldnt they ask for guidance then? I am happy to write docs/FAQs if there are any questions/comments. > That's obviously not the entire story here though - even with better docs, > I'm confident we'd still have a significant problem to consider. Some of > this may well be a result of maintainers simply having too many packages > to deal with. With the traditional "single owner" model of Fedora package > maint there's a tendancy to leave the fixing to the officially assigned > owner. For packages that we see a high volume of CVEs against, we perhaps > need to work ensure there are multiple maintainers recorded against the > package to give some redundancy. > How to do that? ie convince people to co-maintain pkgs with high CVE loads? given that cves are deterrent to pkg maintainers! > Regards, > Daniel > -- Huzaifa Sidhpurwala / Red Hat Product Security Team ___ 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:
Re: Making Fedora secure - Package exit policy for security
On 08/01/2018 01:19 PM, Nikos Mavrogiannopoulos wrote: > On Tue, 2018-07-31 at 09:09 +0530, Huzaifa Sidhpurwala wrote: >> Hi All, >> >> I was asked to bring this issue[1] to the developer community before >> FESCO makes a decision. >> >> In several instances[2] there exists packages in Fedora, in which >> package-maintainers did not patch security issues, for multiple >> reasons >> including 1. non-responsive maintainer 2. issue hard to patch 3. no >> one >> cares? >> >> This is a risk for the distribution, our users and community as a >> whole >> and not to mentioned bad PR :) >> >> I would like to propose the following: >> >> >> 1. If a CRITICAL or IMPORTANT security issue is open against a >> package >> in Fedora-X and by the time X is EOL and the issue is not addressed, >> proactively remove the package from X+1 >> 2. If a MODERATE or LOW security issue is open against a package in >> Fedora -X and by the time X+! is EOL, the issue is not addressed, >> remove >> it from X+2 >> >> Note: >> 1. Once pkg is patches, it can be rebuild and re-introduced into the >> distro >> 2. X/X+1 is the best boundary to remove the insecure packages imo, >> since >> inbetween removals are not possible due to the way mirrors work. >> 3. Maintain a list somewhere (automated maybe) of the list of >> packages >> removed and why. >> 4. Have a list of critical pkg, which cannot be removed which will >> break >> the distro. >> >> The above is not set in stone, but is open for discussion. Let me >> know >> what you guys think! >> >> In the end, i would like you leave you all with this parting link: >> > > Thank you Huzaifa for bringing that up. I have a talk on fedora and > crypto in flock, and my recommendation will be towards having some > process to remove old packages from fedora. CVEs were not the drivers > there, but the continuous expansion of the crypto core which at the end > as you say causes CVEs which no-one addresses. To add to that, we ship > several packages which are the result of an internship, thesis, > packages which are there just in case and all expand the attack > surface. > > So yes, I'd support something like that, and even further than that, if > there is no update (upstream release) for 5 years, the > package+dependencies is marked for removal as well. Cancelling that > process would have to go through a fedora committee. > Thank you very much for supporting me on this. This proposal has come after years of experience in dealing with Security in Red Hat, upstream and Fedora itself. Honestly the volume of pkgs in Fedora is disturbing, more disturbing are fly-by maintainers, who do packaging for university projects etc and then disappear :( > regards, > Nikos > > ___ > 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/message/JR7UNQKX2BSXNTGRSDRKWYDUA3U46V5I/ > -- Huzaifa Sidhpurwala / Red Hat Product Security Team ___ 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/message/CM7I6AI2O777RQUJYRXUEYYENHT6JRJR/
Re: Making Fedora secure - Package exit policy for security
On 08/01/2018 01:41 PM, Daniel P. Berrangé wrote: > On Wed, Aug 01, 2018 at 10:33:11AM +0530, Huzaifa Sidhpurwala wrote: >> On 07/31/2018 08:33 PM, Rex Dieter wrote: >> 1. If a CRITICAL or IMPORTANT security issue is open against a package in Fedora-X and by the time X is EOL and the issue is not addressed, proactively remove the package from X+1 2. If a MODERATE or LOW security issue is open against a package in Fedora -X and by the time X+! is EOL, the issue is not addressed, remove it from X+2 >>> >>> I don't think this is practical, we'll lose half the distro (are at least >>> large chunks). >>> >>> Initially, such a proposal may be possible if generally limited to leaf >>> packages. >>> >> >> So, i did some analysis of the number of packages which would be >> actually removed if we allowed this policy. I generated a list of open >> CVE bugs against X-2 which in this case is Fedora-26 and i got the >> following list: >> >> https://bugzilla.redhat.com/buglist.cgi?bug_status=NEW_status=ASSIGNED=Fedora=SecurityTracking%2C%20_type=allwords_id=9198136=Fedora_format=advanced=26 >> >> If you extract the list of components ,it yields 57 unique components. >> out of that components like xorg-server etc would probably be in the >> critical list. > > binutils is in the list, and without that, we won't have a distro at all ! > Yes, that is why the concept of critical pkgs, binutils and others would obviously be on that list, which means, they cannot be dropped from the distro. > Chances are though, that the bugs were fixed in upstream and so available > in newer Fedora version, so merely F26 left unfixed and the BZ status > outdated. I imagine this probably applies to most open CVEs against > RPMs which have an active upstream community. Its the ones with dead > upstream that and not fixed in Fedora that would be the serious concern. > If Newer fedora is fixed via rebase, the older trackers should be closed with appropriate resolution and comments. I am not asking all the security issues to be resolved in each version of fedora, i am merely asking for proper bookkeeping so that our users can make an informed decision. > Regards, > Daniel > -- Huzaifa Sidhpurwala / Red Hat Product Security Team ___ 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/message/FENPZGAIFU5XSVXKQVNBZ2J457UHOSNV/
[Bug 1611022] perl-App-cpm-0.978 is available
https://bugzilla.redhat.com/show_bug.cgi?id=1611022 Petr Pisar changed: What|Removed |Added Status|ASSIGNED|CLOSED Fixed In Version||perl-App-cpm-0.978-1.fc29 Resolution|--- |RAWHIDE Last Closed||2018-08-02 02:07:42 --- Comment #1 from Petr Pisar --- A bug-fix release suitable for Fedora ≥ 29. -- 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/message/UPSANZKQX62DVKBG4VEMZW7Y7NSPNLBA/
