[EPEL-devel] Fedora EPEL 7 updates-testing report
The following Fedora EPEL 7 Security updates need testing: Age URL 175 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-3835d39d1a unrtf-0.21.9-8.el7 126 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-f9d6ff695a bibutils-6.6-1.el7 ghc-hs-bibutils-6.6.0.0-1.el7 pandoc-citeproc-0.3.0.1-4.el7 109 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-3c9292b62d condor-8.6.11-1.el7 24 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-9051b49e75 suricata-4.0.6-1.el7 15 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-a09ace87bb php-PHPMailer-5.2.27-1.el7 11 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-c25e48ded1 bird-1.6.4-2.el7 10 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-2206653eb9 python-django-1.11.13-4.el7 python-django16-1.6.11.7-5.el7 10 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-3f65916e08 moodle-3.1.15-1.el7 9 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-cf66ab47c5 dnsdist-1.3.3-1.el7 5 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-a4f72b6533 cobbler-2.8.4-4.el7 2 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-bffc0108f2 pdns-recursor-4.1.8-1.el7 1 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-c0e5a2a81f wildmidi-0.3.15-1.el7 1 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2018-0346a55d0f nagios-4.4.2-3.el7 The following builds have been pushed to Fedora EPEL 7 updates-testing fts-monitoring-3.7.8-2.el7 radeontop-1.2-0.1.20181031git7474f50.el7 Details about builds: fts-monitoring-3.7.8-2.el7 (FEDORA-EPEL-2018-d73375e051) FTS3 Web Application for monitoring Update Information: * update django dependency to python-django16 ChangeLog: * Sat Dec 1 2018 Andrea Manzi - 3.7.8-2 - update django dep to 1.6 radeontop-1.2-0.1.20181031git7474f50.el7 (FEDORA-EPEL-2018-8a6d59a03c) View GPU utilization of AMD/ATI Radeon devices Update Information: This update add support of newer AMD APU and Radeon GPU ChangeLog: * Fri Nov 30 2018 Luya Tshimbalanga 1.2-0.1.20181031git7474f50 - Update to 20181031 which support newer AMD APU and GPU * Mon Mar 26 2018 Luya Tshimbalanga 1.1-1 - Update to 1.1 * Sun Mar 4 2018 Luya Tshimbalanga 1.0-20180106git07ec13 - Latest upstream git snapshot * Sat Aug 5 2017 Luya Tshimbalanga - 1.0-5 - Add metainfo file ___ 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
Re: Orphaned packages need new maintainers (will be retired in 3 weeks)
On Sat, 2018-12-01 at 10:12 -0500, Nico Kadel-Garcia wrote: > On Sat, Dec 1, 2018 at 6:59 AM Frank Crawford > wrote: > > On Sat, 2018-12-01 at 11:38 +, Zbigniew Jędrzejewski-Szmek wrote: > > On Sat, Dec 01, 2018 at 10:14:14PM +1100, Frank Crawford wrote: > > On Fri, 2018-11-30 at 14:15 +0100, Miro Hrončok wrote: > > > Anyone know why this was orphaned? There doesn't seem to be any > > message about it. > > > s3cmd orphan 0 weeks ago > > Is there any need for s3cmd with awscli available and supported? That is a good question, which I haven't really looked at in detail, I just know that I use it a bit in various scripts, etc, and it is still supported upstream with recent changes. Since the swap from s3cmd to awscli isn't a straight drop-in replacement, I suspect there are probably a few similar to me who won't change over for a while, if ever. Regards Frank ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: What does delaying F31 mean for packagers/users?
On Sat, Dec 1, 2018 at 10:24 AM Stephen John Smoogen wrote: > > On Sat, 1 Dec 2018 at 08:50, Nico Kadel-Garcia wrote: > > > > Folks, hi. > > > > Planning for a specific delay for a specific reason is one thing. But > > the same design philosophy reasons that apply to Fedora 31 have > > applied to almost every other Fedora releases, and changing to an > > annual cycle is going to drive people *nuts* when updates for their > > particular critical components get delayed up to 18 months because > > they missed the *current* release and have to wait for the next major > > release for the dependencies to be built up. This especially plays out > > with tools that use many distinct small modules by different authors, > > such as Python. Have you *looked* at what happens if python modules > > are even slightly out of date, and the dependency chain that "pip > > instlal" brings in? > > > > I think the thinking is that you would make these modules and would > just make them available during a release. You put a 12 month lifetime > on each module set you are running and put out updated ones when you > are ready to do so. The modules get retired over time and you are > running your own 'release'. Of course this works better if packagers > team up together and own the module versus trying to do it all > themselves.. which is also assumed but may not have been realized by > the packagers yet :). The problem is maintaining the dependency chain. I tried to do this for "airflow" under Fedora 28, and it became painful to try to build chain. I used to do it for RHEL and CentOS 7 for previous releases. But getting the dependencies resolved for very specific python module requirements, and the older and newer versions of critical modules, just got out of hand. I've found it much easier to work from Fedora at or near the bleeding edge of all infrastructure components than to backport mixed versions of individual components for compatibility. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Orphaned packages need new maintainers (will be retired in 3 weeks)
On Friday, 30 November 2018 at 14:15, Miro Hrončok wrote: > The following packages are orphaned and will be retired when they > are orphaned for six weeks, unless someone adopts them. If you know for sure > that the package should be retired, please do so now with a proper reason: > https://fedoraproject.org/wiki/How_to_remove_a_package_at_end_of_life > > Note: If you received this mail directly you (co)maintain one of the > affected packages or a package that depends on one. Please adopt the > affected package or retire your depending package to avoid broken > dependencies, otherwise your package will be retired when the affected > package gets retired. > > Unretire packages at https://pagure.io/releng/issues > > Full breakdown of dependent packages is at: > > https://churchyard.fedorapeople.org/orphans.txt > that have been orphaned for 6+ weeks in 3 weeks from now, will be sending > e-mails like this each week. > > Orphaned packages: [...] > rathann: js-jquery1 This is a dependency of lazygal, which bundles an old 1.11.0 version and which I unbundle during build. I reported this upstream: https://bitbucket.org/niol/lazygal/issues/27/bundled-jquery-1110-is-old-and-vulnerable Regards, Dominik -- Fedora https://getfedora.org | RPMFusion http://rpmfusion.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan ___ 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
[EPEL-devel] Re: New developer toolkit beta
On Mon, 26 Nov 2018 at 14:44, Tom Callaway wrote: > > Just checking in on this again, still need this update to build Chromium > for EPEL7. > Sorry for the delay.. I spent some time looking for a new repository tree and it turns out they put it in the regular ones. So everyone needing newer gcc. You can use dts-8 for aarch64/ppc64le and x86_64 [root@batcave01 rhel7][PROD]# ls -l */rhel-server-rhscl-7-rpms/Packages/ | grep -- "devtoolset-8-gcc-c++" -rw-r--r--. 1 root sysadmin-main 10828196 Oct 23 08:02 devtoolset-8-gcc-c++-8.2.1-3.el7.aarch64.rpm -rw-r--r--. 1 root sysadmin-main 12967892 Oct 23 07:55 devtoolset-8-gcc-c++-8.2.1-3.el7.ppc64le.rpm -rw-r--r--. 1 root sysadmin-main 12366848 Oct 23 08:00 devtoolset-8-gcc-c++-8.2.1-3.el7.x86_64.rpm > ~tom > > On 11/2/18 1:05 PM, Tom Callaway wrote: > > > > > > On 10/30/18 11:19 AM, Stephen John Smoogen wrote: > >> On Tue, 30 Oct 2018 at 10:36, Tom Callaway wrote: > >>> > >>> https://developers.redhat.com/blog/2018/10/24/gcc-8-and-tools-now-in-beta-for-red-hat-enterprise-linux-6-and-7/ > >>> > >>> Can we get this beta into the epel build root? Chromium needs this to > >>> build again. > >>> > >> > >> I will see what I can do later this week. I need to get the 7.6 > >> buildroots 'fixed' and try to work out how many packages need to be > >> rebuilt to work with that. > > > > Thanks, please reply back when it is done. > > > > ~tom > > -- Stephen J Smoogen. ___ 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
[Bug 1652477] Upgrade perl-Config-Model to 2.128
https://bugzilla.redhat.com/show_bug.cgi?id=1652477 Fedora Update System changed: What|Removed |Added Status|ON_QA |CLOSED Fixed In Version|perl-Config-Model-2.128-1.f |perl-Config-Model-2.128-1.f |c30 |c30 ||perl-Config-Model-2.128-1.f ||c29 Resolution|--- |ERRATA Last Closed||2018-12-01 15:40:27 --- Comment #3 from Fedora Update System --- perl-Config-Model-2.128-1.fc29 has been pushed to the Fedora 29 stable repository. If problems still persist, please make note of it in this bug report. -- You are receiving this mail because: You are on the CC list for the bug. ___ perl-devel mailing list -- perl-devel@lists.fedoraproject.org To unsubscribe send an email to perl-devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/perl-devel@lists.fedoraproject.org
Re: Improving the compose: leave the current compose in place
On Tue, Nov 27, 2018 at 7:59 AM Owen Taylor wrote: > > A lot of discussion about improving the compose process seem to end up > with a "reality check" - that ideas have already been tried but don't > work because of requirements a) b) c) d). You can't have the pony, but > maybe if a lot of effort is put into it, you can have a faster rocking > horse. > > If want to fundamentally improve the Fedora workflow we need compose > ponies, we can't just have rocking horses! There have several efforts to improve Pungi performance over time. Is there any email list or communication channel where this effort could be coordinated? I work on a project in Ceph that uses Pungi a lot, so I'm really interested in making composes as fast as possible. Our Jenkins system runs Pungi several times a day (every time a build completes in Koji), so that we can deliver composes to QE immediately. I'd like to run it even more frequently (like on every pull request scratch build). Maybe we could write a dedicated page in Pungi's upstream documentation, "performance tips for making Pungi as fast as possible". It could explain the dogpile.cache stuff, hardlinks vs http, etc. > I don't know what the system would look like exactly, but you could > imagine things like: > > * Composed of several micro-composes (micro-compose-services?) to > avoid blocking on everything completing successfully. > > * Able to do speculative composes for CI > > * Either x86_64-only, or with decoupled architectures so that we can > throw x86_64 hardware (or cloud resources) at it, and make it super > fast. > > * No IO /mnt/koji during the compose - having a big network share be > central to the process creates a performance bottleneck, makes it hard > to move to the cloud, and potentially adds a lot of "noise" to > figuring out what is going on where things are slow because of some > other entirely different thing is goin gon. This is a great idea, although it's a little tricky to do everything in a local tmpdir and still take advantage of the speed that NFS hardlinks provide. > Add your own bullet points :-) Another hairbrained idea: reduce or eliminate Pungi's thread model and make it asynchronous, using https://github.com/ktdreyer/txkoji :) ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: [HEADS UP] tinyxml2 SONAME bump (7.x)
On 11/29/18 10:08 AM, Igor Gnatenko wrote: And it's in rawhide. FYI: Kodi links against 'tinyxml' and not 'tinyxml2'. ___ 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
Fedora Rawhide-20181201.n.0 compose check report
No missing expected images. Failed openQA tests: 16/142 (x86_64), 3/24 (i386), 1/2 (arm) New failures (same test did not fail in Rawhide-20181130.n.0): ID: 314638 Test: x86_64 Server-dvd-iso realmd_join_sssd URL: https://openqa.fedoraproject.org/tests/314638 ID: 314641 Test: x86_64 Server-dvd-iso server_freeipa_replication_client URL: https://openqa.fedoraproject.org/tests/314641 ID: 314662 Test: x86_64 Workstation-live-iso desktop_browser URL: https://openqa.fedoraproject.org/tests/314662 ID: 314674 Test: x86_64 KDE-live-iso install_no_user URL: https://openqa.fedoraproject.org/tests/314674 ID: 314732 Test: x86_64 universal install_blivet_no_swap@uefi URL: https://openqa.fedoraproject.org/tests/314732 ID: 314750 Test: x86_64 universal upgrade_server_64bit URL: https://openqa.fedoraproject.org/tests/314750 Old failures (same test failed in Rawhide-20181130.n.0): ID: 314645 Test: x86_64 Server-dvd-iso modularity_tests URL: https://openqa.fedoraproject.org/tests/314645 ID: 314656 Test: x86_64 Workstation-live-iso base_services_start URL: https://openqa.fedoraproject.org/tests/314656 ID: 314664 Test: x86_64 Workstation-live-iso desktop_notifications_postinstall URL: https://openqa.fedoraproject.org/tests/314664 ID: 314666 Test: x86_64 Workstation-boot-iso memory_check URL: https://openqa.fedoraproject.org/tests/314666 ID: 314667 Test: x86_64 Workstation-boot-iso memory_check@uefi URL: https://openqa.fedoraproject.org/tests/314667 ID: 314670 Test: i386 Workstation-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/314670 ID: 314671 Test: i386 Workstation-boot-iso memory_check URL: https://openqa.fedoraproject.org/tests/314671 ID: 314686 Test: arm Minimal-raw_xz-raw.xz install_arm_image_deployment_upload URL: https://openqa.fedoraproject.org/tests/314686 ID: 314694 Test: x86_64 Silverblue-dvd_ostree-iso base_services_start URL: https://openqa.fedoraproject.org/tests/314694 ID: 314758 Test: x86_64 universal install_cyrillic_language URL: https://openqa.fedoraproject.org/tests/314758 ID: 314764 Test: x86_64 universal install_european_language URL: https://openqa.fedoraproject.org/tests/314764 ID: 314765 Test: x86_64 universal install_arabic_language URL: https://openqa.fedoraproject.org/tests/314765 ID: 314766 Test: x86_64 universal install_asian_language URL: https://openqa.fedoraproject.org/tests/314766 ID: 314787 Test: i386 universal upgrade_2_desktop_32bit URL: https://openqa.fedoraproject.org/tests/314787 Soft failed openQA tests: 2/24 (i386), 3/142 (x86_64) (Tests completed, but using a workaround for a known bug) New soft failures (same test did not soft fail in Rawhide-20181130.n.0): ID: 314648 Test: i386 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/314648 ID: 314760 Test: x86_64 universal upgrade_2_server_64bit URL: https://openqa.fedoraproject.org/tests/314760 Old soft failures (same test soft failed in Rawhide-20181130.n.0): ID: 314649 Test: i386 Server-dvd-iso install_default URL: https://openqa.fedoraproject.org/tests/314649 ID: 314673 Test: x86_64 KDE-live-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/314673 ID: 314751 Test: x86_64 universal upgrade_server_domain_controller URL: https://openqa.fedoraproject.org/tests/314751 Passed openQA tests: 118/142 (x86_64), 19/24 (i386) New passes (same test did not pass in Rawhide-20181130.n.0): ID: 314621 Test: x86_64 Server-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/314621 ID: 314622 Test: x86_64 Server-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/314622 ID: 314650 Test: x86_64 Everything-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/314650 ID: 314651 Test: x86_64 Everything-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/314651 ID: 314652 Test: i386 Everything-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/314652 ID: 314665 Test: x86_64 Workstation-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/314665 ID: 314668 Test: x86_64 Workstation-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/314668 ID: 314698 Test: x86_64 Silverblue-dvd_ostree-iso desktop_browser URL: https://openqa.fedoraproject.org/tests/314698 ID: 314716 Test: x86_64 universal install_software_raid URL: https://openqa.fedoraproject.org/tests/314716 Skipped openQA tests: 1 of 168 Installed system changes in test x86_64 Server-dvd-iso install_default_upload: System load changed from 1.08 to 1.25 Previous test data: https://openqa.fedoraproject.org/tests/314472#downloads Current test data: https://openqa.fedoraproject.org/tests/314623#downloads Installed system changes in test x86_64 Server-dvd-iso install_default@uefi: System load changed from 1.05 to 1.78
Re: What does delaying F31 mean for packagers/users?
On Sat, 1 Dec 2018 at 08:50, Nico Kadel-Garcia wrote: > > Folks, hi. > > Planning for a specific delay for a specific reason is one thing. But > the same design philosophy reasons that apply to Fedora 31 have > applied to almost every other Fedora releases, and changing to an > annual cycle is going to drive people *nuts* when updates for their > particular critical components get delayed up to 18 months because > they missed the *current* release and have to wait for the next major > release for the dependencies to be built up. This especially plays out > with tools that use many distinct small modules by different authors, > such as Python. Have you *looked* at what happens if python modules > are even slightly out of date, and the dependency chain that "pip > instlal" brings in? > I think the thinking is that you would make these modules and would just make them available during a release. You put a 12 month lifetime on each module set you are running and put out updated ones when you are ready to do so. The modules get retired over time and you are running your own 'release'. Of course this works better if packagers team up together and own the module versus trying to do it all themselves.. which is also assumed but may not have been realized by the packagers yet :). -- Stephen J Smoogen. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Orphaned packages need new maintainers (will be retired in 3 weeks)
On Sat, Dec 1, 2018 at 6:59 AM Frank Crawford wrote: > > On Sat, 2018-12-01 at 11:38 +, Zbigniew Jędrzejewski-Szmek wrote: > > On Sat, Dec 01, 2018 at 10:14:14PM +1100, Frank Crawford wrote: > > On Fri, 2018-11-30 at 14:15 +0100, Miro Hrončok wrote: > > > Anyone know why this was orphaned? There doesn't seem to be any > > message about it. > > > s3cmd orphan 0 weeks ago Is there any need for s3cmd with awscli available and supported? ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: What does delaying F31 mean for packagers/users?
Folks, hi. Planning for a specific delay for a specific reason is one thing. But the same design philosophy reasons that apply to Fedora 31 have applied to almost every other Fedora releases, and changing to an annual cycle is going to drive people *nuts* when updates for their particular critical components get delayed up to 18 months because they missed the *current* release and have to wait for the next major release for the dependencies to be built up. This especially plays out with tools that use many distinct small modules by different authors, such as Python. Have you *looked* at what happens if python modules are even slightly out of date, and the dependency chain that "pip instlal" brings in? ___ 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
Fedora rawhide compose report: 20181201.n.0 changes
OLD: Fedora-Rawhide-20181130.n.0 NEW: Fedora-Rawhide-20181201.n.0 = SUMMARY = Added images:2 Dropped images: 5 Added packages: 11 Dropped packages:0 Upgraded packages: 64 Downgraded packages: 0 Size of added packages: 1.46 MiB Size of dropped packages:0 B Size of upgraded packages: 6.03 GiB Size of downgraded packages: 0 B Size change of upgraded packages: -2.19 MiB Size change of downgraded packages: 0 B = ADDED IMAGES = Image: Python_Classroom live i386 Path: Labs/i386/iso/Fedora-Python-Classroom-Live-i386-Rawhide-20181201.n.0.iso Image: Python_Classroom live x86_64 Path: Labs/x86_64/iso/Fedora-Python-Classroom-Live-x86_64-Rawhide-20181201.n.0.iso = DROPPED IMAGES = Image: Workstation raw-xz aarch64 Path: Workstation/aarch64/images/Fedora-Workstation-Rawhide-20181130.n.0.aarch64.raw.xz Image: Python_Classroom vagrant-libvirt i386 Path: Labs/i386/images/Fedora-Python-Classroom-Vagrant-Rawhide-20181130.n.0.i386.vagrant-libvirt.box Image: Container_Minimal_Base docker aarch64 Path: Container/aarch64/images/Fedora-Container-Minimal-Base-Rawhide-20181130.n.0.aarch64.tar.xz Image: Server raw-xz aarch64 Path: Server/aarch64/images/Fedora-Server-Rawhide-20181130.n.0.aarch64.raw.xz Image: Python_Classroom vagrant-virtualbox i386 Path: Labs/i386/images/Fedora-Python-Classroom-Vagrant-Rawhide-20181130.n.0.i386.vagrant-virtualbox.box = ADDED PACKAGES = Package: golang-github-google-gopacket-1.1.15-1.fc30 Summary: This library provides packet decoding capabilities for Go RPMs:golang-github-google-gopacket-devel Size:619.71 KiB Package: golang-github-mdlayher-raw-0-0.2.20181130gitfa5ef33.fc30 Summary: Enables reading and writing data at the network driver level RPMs:golang-github-mdlayher-raw-devel Size:104.15 KiB Package: golang-github-xdg-stringprep-0-0.2.20181130git73f8eec.fc30 Summary: Provides an implementation of the stringprep algorithm (RFC-3454) RPMs:golang-github-xdg-stringprep-devel Size:27.02 KiB Package: golang-gopkg-resty-1-1.10.2-1.fc30 Summary: Simple HTTP and REST client library for Go RPMs:golang-gopkg-resty-1-devel Size:50.63 KiB Package: python-magic-wormhole-0.11.2-1.fc30 Summary: Securely transfer data between computers RPMs:magic-wormhole python-magic-wormhole-doc python3-magic-wormhole Size:460.00 KiB Package: rust-flate2-crc-0.1.1-1.fc30 Summary: SIMD acceleration for CRC-32 checksums used in the gzip format RPMs:rust-flate2-crc+default-devel rust-flate2-crc-devel Size:24.43 KiB Package: rust-rand_chacha-0.1.0-1.fc30 Summary: ChaCha random number generator RPMs:rust-rand_chacha+default-devel rust-rand_chacha-devel Size:27.59 KiB Package: rust-rand_hc-0.1.0-1.fc30 Summary: HC128 random number generator RPMs:rust-rand_hc+default-devel rust-rand_hc-devel Size:27.16 KiB Package: rust-rand_isaac-0.1.1-1.fc30 Summary: ISAAC random number generator RPMs:rust-rand_isaac+default-devel rust-rand_isaac+serde-devel rust-rand_isaac+serde1-devel rust-rand_isaac+serde_derive-devel rust-rand_isaac-devel Size:52.91 KiB Package: rust-rand_pcg-0.1.1-1.fc30 Summary: Selected PCG random number generators RPMs:rust-rand_pcg+bincode-devel rust-rand_pcg+default-devel rust-rand_pcg+serde-devel rust-rand_pcg+serde1-devel rust-rand_pcg+serde_derive-devel rust-rand_pcg-devel Size:55.12 KiB Package: rust-rand_xorshift-0.1.0-1.fc30 Summary: Xorshift random number generator RPMs:rust-rand_xorshift+default-devel rust-rand_xorshift+serde-devel rust-rand_xorshift+serde1-devel rust-rand_xorshift+serde_derive-devel rust-rand_xorshift-devel Size:46.29 KiB = DROPPED PACKAGES = = UPGRADED PACKAGES = Package: annobin-8.64-1.fc30 Old package: annobin-8.63-1.fc30 Summary: Binary annotation plugin for GCC RPMs: annobin Size: 1.06 MiB Size change: 752 B Changelog: * Fri Nov 30 2018 Nick Clifton - 8.64-1 - Annocheck: Skip gaps in PPC64 executables covered by start_bcax_ symbols. (#1630564) Package: appcenter-3.0.1-2.fc30 Old package: appcenter-3.0.1-1.fc30 Summary: Software Center from elementary RPMs: appcenter appcenter-gnome-shell-search-provider Size: 2.21 MiB Size change: -4.96 KiB Changelog: * Fri Nov 30 2018 Fabio Valentini - 3.0.1-2 - Drop elementaryOS blacklist in favor of the version shipped with appcenter. Package: buildah-1.6-6.dev.git2b582d3.fc30 Old package: buildah-1.6-5.dev.git6e00183.fc30 Summary: A command line tool used for creating OCI Images RPMs: buildah Size: 23.59 MiB Size change: 7.79 KiB Changelog: * Sat Dec 01 2018 Lokesh Mandvekar (Bot) - 1.6-6.dev.git2b582d3 - autobuilt 2b582d3 Package: buku-4.0-2.fc30 Old package: buku-4.0-1.fc30 Summary: Powerful command-line bookmark manager RPMs: buku Size: 74.85 KiB Size change: 228 B Changelog: * Fri Nov 30 2018 Robert-Andr?? Mauchin
Re: Orphaned packages need new maintainers (will be retired in 3 weeks)
On Sat, 2018-12-01 at 11:38 +, Zbigniew Jędrzejewski-Szmek wrote: > On Sat, Dec 01, 2018 at 10:14:14PM +1100, Frank Crawford wrote: > On Fri, 2018-11-30 at 14:15 +0100, Miro Hrončok wrote: > > Anyone know why this was orphaned? There doesn't seem to be any > message about it. > > s3cmd orphan 0 weeks ago > > If no one has any idea I'm willing to take it on. > > orphan != retired. You don't need a reason to orphan something other than > just not having enough time. Yep, and if that is the case, I'm happy to take it on, I just don't want to take on something that has an underlying issue I have missed. And I mainly asked as it was just orphaned, and I may have missed a message about it. > Zbyszek Frank ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Orphaned packages need new maintainers (will be retired in 3 weeks)
On Sat, Dec 01, 2018 at 10:14:14PM +1100, Frank Crawford wrote: > On Fri, 2018-11-30 at 14:15 +0100, Miro Hrončok wrote: > > Anyone know why this was orphaned? There doesn't seem to be any > message about it. > > > s3cmd orphan 0 weeks ago > > If no one has any idea I'm willing to take it on. orphan != retired. You don't need a reason to orphan something other than just not having enough time. Zbyszek ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Orphaned packages need new maintainers (will be retired in 3 weeks)
On Fri, 2018-11-30 at 14:15 +0100, Miro Hrončok wrote: Anyone know why this was orphaned? There doesn't seem to be any message about it. > s3cmd orphan 0 weeks ago If no one has any idea I'm willing to take it on. Regards Frank ___ 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
