Re: Netcat
On Thu, Jun 16, 2016 at 05:18:06PM +, Christopher wrote: > The last information I found about nc on this mailing list is that nc was > obsoleted by nmap-ncat. Can anybody tell me if this is accurate? Am I just > giving myself a headache for no reason? Should nc and nc6 simply be dropped > entirely? > > Thanks. Yes, this is accurate. P signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
weld-core license changes
Hi weld-core package changes from ASL 2.0 and LGPLv2+ and (CDDL or GPLv2 with exceptions) to ASL 2.0 and (CDDL or GPLv2 with exceptions) and LGPLv2+ and MIT and OFL regards .g -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Fedora rawhide compose report: 20160620.n.0 changes
OLD: Fedora-Rawhide-20160619.n.0 NEW: Fedora-Rawhide-20160620.n.0 = SUMMARY = Added images:6 Dropped images: 4 Added packages: 0 Dropped packages:0 Upgraded packages: 17 Downgraded packages: 0 Size of added packages: 0.00 B Size of dropped packages:0.00 B Size of upgraded packages: 57.01 MiB Size of downgraded packages: 0.00 B Size change of upgraded packages: 119.21 KiB Size change of downgraded packages: 0.00 B = ADDED IMAGES = Image: Mate live i386 Path: Spins/i386/iso/Fedora-MATE_Compiz-Live-i386-Rawhide-20160620.n.0.iso Image: Mate live x86_64 Path: Spins/x86_64/iso/Fedora-MATE_Compiz-Live-x86_64-Rawhide-20160620.n.0.iso Image: Astronomy_KDE live x86_64 Path: Labs/x86_64/iso/Fedora-Astronomy_KDE-Live-x86_64-Rawhide-20160620.n.0.iso Image: Astronomy_KDE live i386 Path: Labs/i386/iso/Fedora-Astronomy_KDE-Live-i386-Rawhide-20160620.n.0.iso Image: SoaS live x86_64 Path: Spins/x86_64/iso/Fedora-SoaS-Live-x86_64-Rawhide-20160620.n.0.iso Image: SoaS live i386 Path: Spins/i386/iso/Fedora-SoaS-Live-i386-Rawhide-20160620.n.0.iso = DROPPED IMAGES = Image: Scientific_KDE live x86_64 Path: Labs/x86_64/iso/Fedora-Scientific_KDE-Live-x86_64-Rawhide-20160619.n.0.iso Image: Security live i386 Path: Labs/i386/iso/Fedora-Security-Live-i386-Rawhide-20160619.n.0.iso Image: Security live x86_64 Path: Labs/x86_64/iso/Fedora-Security-Live-x86_64-Rawhide-20160619.n.0.iso Image: Scientific_KDE live i386 Path: Labs/i386/iso/Fedora-Scientific_KDE-Live-i386-Rawhide-20160619.n.0.iso = ADDED PACKAGES = = DROPPED PACKAGES = = UPGRADED PACKAGES = Package: 4Pane-4.0-2.fc25 Old package: 4Pane-4.0-1.fc25 Summary: Multi-pane, detailed-list file manager RPMs: 4Pane Size: 4302414 bytes Size change: 3972 bytes Changelog: * Sun Jun 19 2016 Mamoru TASAKA - 4.0-2 - Patch from the upstream to fix sizing and color issue with GTK 3.20 (bug 1345924) Package: copyq-2.7.1-1.fc25 Old package: copyq-2.7.0-1.fc25 Summary: Advanced clipboard manager RPMs: copyq Size: 4531698 bytes Size change: -135832 bytes Changelog: * Sun Jun 19 2016 Gerald Cox - 2.7.1-1 - Upstream release rhbz#1347965 Package: hydra-8.2-1.fc25 Old package: hydra-8.1-3.fc24 Summary: Very fast network log-on cracker RPMs: hydra hydra-frontend Size: 1601088 bytes Size change: 10820 bytes Changelog: * Fri Jun 17 2016 Michal Ambroz 8.2-1 - Update to 8.2 Package: josm-0-0.78.10327svn.fc25 Old package: josm-0-0.77.9979svn.fc25 Summary: An editor for OpenStreetMap (OSM) RPMs: josm josm-javadoc Size: 18707212 bytes Size change: 218576 bytes Changelog: * Sun Jun 19 2016 C??dric OLIVIER 0-0.78.10327svn - Update to 10327 svn revision Package: libguestfs-1:1.33.38-1.fc25 Old package: libguestfs-1:1.33.37-1.fc25 Summary: Access and modify virtual machine disk images RPMs: erlang-libguestfs libguestfs libguestfs-bash-completion libguestfs-benchmarking libguestfs-devel libguestfs-forensics libguestfs-gfs2 libguestfs-gobject libguestfs-gobject-devel libguestfs-gobject-doc libguestfs-hfsplus libguestfs-inspect-icons libguestfs-java libguestfs-java-devel libguestfs-javadoc libguestfs-jfs libguestfs-live-service libguestfs-man-pages-ja libguestfs-man-pages-uk libguestfs-nilfs libguestfs-reiserfs libguestfs-rescue libguestfs-rsync libguestfs-tools libguestfs-tools-c libguestfs-xfs libguestfs-zfs lua-guestfs ocaml-libguestfs ocaml-libguestfs-devel perl-Sys-Guestfs php-libguestfs python2-libguestfs python3-libguestfs ruby-libguestfs virt-dib virt-v2v Size: 24872768 bytes Size change: 23872 bytes Changelog: * Sun Jun 19 2016 Richard W.M. Jones - 1:1.33.38-1 - New upstream version 1.33.38. Package: maven-archiver-3.1.1-1.fc25 Old package: maven-archiver-3.0.2-1.fc25 Summary: Maven Archiver RPMs: maven-archiver maven-archiver-javadoc Size: 74972 bytes Size change: 204 bytes Changelog: * Mon Jun 20 2016 Mikolaj Izdebski - 0:3.1.1-1 - Update to upstream version 3.1.1 Package: perl-MCE-1.800-1.fc25 Old package: perl-MCE-1.708-1.fc25 Summary: Many-core Engine for Perl providing parallel processing capabilities RPMs: perl-MCE perl-MCE-tools Size: 238476 bytes Size change: 2112 bytes Changelog: * Sun Jun 19 2016 Paul Howarth - 1.800-1 - Update to 1.800 - Fixed dequeue (count) in MCE::Queue for standalone mode - On Windows, improved stablity and feature parity with UNIX - Use Sereal 3.008+ automatically if available on the box - Added support for cyclical include of MCE Core, MCE Models, and MCE Queue by scoping the configuration to the local package (CPAN RT#107384) Package: perl-Test-Simple-1.302030-1.fc25 Old package: perl-Test-Simple-1.302026-1.fc25 Summary: Basic utilities for writing tests RPMs: perl-Test-Simple Size
[Modularity] RFC: rebuilding components of modules and namespace issues
Hi all, One month ago Petr Šabata posted a module build proposal here on this list. [1] I'd like to gather some ideas about the very first of his key points as it poses some problems with our current buildsystem: > - building a module means building the components it contains and > composing a module deliverable (a repository, an image, other) Rebuilding compoments is necessary as the buildroot of modules can be quite different from package builds which usually just take whatever package is tagged last into a koji tag. For modules it will depend on the modules definition. But we can't just simply rebuild the same RPM (same name-version-release) in koji for a module. koji correctly doesn't allow that. To make it worse, that same RPM might be required by different modules with different buildroots, thus needing a rebuild there as well. The current idea is to use the dist tag for this and let privileged users or koji itself (based on some rules) overwrite the %dist tag for builds of module components. This lets us automate those builds fairly easily. Another approach would be to modify the package release for each rebuild. That still allows us to automate rebuilds to some extend, but for example finding an upgrade path might get a little messy. Does anyone have any other ideas for this problem ? Karsten [1] https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org/message/ONSR4IHJUASBEANEXZVMFGFHDE565XV3/ -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Fedora Rawhide-20160620.n.0 compose check report
Missing expected images: Cloud_base raw-xz i386 Atomic raw-xz x86_64 Kde raw-xz armhfp Minimal raw-xz armhfp Failed openQA tests: 10/83 (x86_64), 1/17 (i386) ID: 23396 Test: x86_64 Everything-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/23396 ID: 23400 Test: x86_64 Workstation-live-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/23400 ID: 23406 Test: x86_64 Workstation-boot-iso install_default@uefi URL: https://openqa.fedoraproject.org/tests/23406 ID: 23409 Test: x86_64 Atomic-boot-iso install_default URL: https://openqa.fedoraproject.org/tests/23409 ID: 23431 Test: x86_64 Server-dvd-iso server_cockpit_basic URL: https://openqa.fedoraproject.org/tests/23431 ID: 23432 Test: x86_64 Server-dvd-iso realmd_join_cockpit URL: https://openqa.fedoraproject.org/tests/23432 ID: 23445 Test: x86_64 universal upgrade_2_server_64bit URL: https://openqa.fedoraproject.org/tests/23445 ID: 23446 Test: x86_64 universal upgrade_2_kde_64bit URL: https://openqa.fedoraproject.org/tests/23446 ID: 23467 Test: x86_64 universal install_iscsi URL: https://openqa.fedoraproject.org/tests/23467 ID: 23483 Test: x86_64 universal upgrade_kde_64bit URL: https://openqa.fedoraproject.org/tests/23483 ID: 23493 Test: i386 universal upgrade_desktop_32bit URL: https://openqa.fedoraproject.org/tests/23493 Passed openQA tests: 73/83 (x86_64), 16/17 (i386) -- Mail generated by check-compose: https://git.fedorahosted.org/cgit/fedora-qa.git/tree/check-compose -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: [Modularity] RFC: rebuilding components of modules and namespace issues
Dne 20.6.2016 v 14:18 Karsten Hopp napsal(a): > Does anyone have any other ideas for this problem ? Rebuild it in Copr? -- Miroslav Suchy, RHCA Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: [Modularity] RFC: rebuilding components of modules and namespace issues
Am 20.06.2016 um 14:48 schrieb Miroslav Suchý: Dne 20.6.2016 v 14:18 Karsten Hopp napsal(a): Does anyone have any other ideas for this problem ? Rebuild it in Copr? > Copy doesn't allow multiple builds with the same N-V-R either according to this: https://fedorahosted.org/copr/wiki/UserDocs#WhathappenswhenItrytobuildapackagewiththesameversionnumber I also couldn't find any information about defining your own build environments in copr. I know that in koji privileged users can set up their own tag with exactly those package tagged in there that they need (koji-shadow works like this for example). Does copr allow something similar ? Karsten -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: [Modularity] RFC: rebuilding components of modules and namespace issues
On Mon, Jun 20, 2016 at 02:18:59PM +0200, Karsten Hopp wrote: > The current idea is to use the dist tag for this and let privileged users or > koji itself (based on some rules) overwrite the %dist tag for builds of > module components. This lets us automate those builds fairly easily. Obviously +1 here but you know that :) > Another approach would be to modify the package release for each rebuild. > That still allows us to automate rebuilds to some extend, but for example > finding an upgrade path might get a little messy. We don't always use the SPEC HEAD so this wouldn't be very helpful; the modulemd file points to particular commit hashes you wish to build -- you would need to branch them and bump the release in the branch, only (possibly, it depends on you handle it) creating more future conflicts. -1 here. P signature.asc Description: PGP signature -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
[POC-change] Fedora packages point of contact updates
Change in package status over the last 168 hours 5 packages were orphaned libntlm [epel7] was orphaned by till NTLMv1 authentication library https://admin.fedoraproject.org/pkgdb/package/libntlm rhncfg [f23, f22, master, f24] was orphaned by msuchy Spacewalk Configuration Client Libraries https://admin.fedoraproject.org/pkgdb/package/rhncfg sectool [f23, f22, f24] was orphaned by mildew A security audit system and intrusion detection system https://admin.fedoraproject.org/pkgdb/package/sectool spacewalk-backend [el6, el5] was orphaned by msuchy Common programs needed to be installed on the Spacewalk servers/proxies https://admin.fedoraproject.org/pkgdb/package/spacewalk-backend tagsoup [el6] was orphaned by gil A SAX-compliant HTML parser written in Java https://admin.fedoraproject.org/pkgdb/package/tagsoup 4 packages were retired cinepaint [master, f24] was retired by till Painting and image retouching program https://admin.fedoraproject.org/pkgdb/package/cinepaint ndctl [epel7] was retired by djbw Manage "libnvdimm" subsystem devices (Non-volatile Memory) https://admin.fedoraproject.org/pkgdb/package/ndctl sectool [master] was retired by mildew A security audit system and intrusion detection system https://admin.fedoraproject.org/pkgdb/package/sectool xcm [master, f24] was retired by till X Color Management tools https://admin.fedoraproject.org/pkgdb/package/xcm 4 packages unorphaned - oyranos [master, f24] was unorphaned by till A Colour Management System (CMS) on operating system level https://admin.fedoraproject.org/pkgdb/package/oyranos python-mtTkinter [f23, f22, master, f24] was unorphaned by pwalter A thread-safe version of Tkinter https://admin.fedoraproject.org/pkgdb/package/python-mtTkinter splint [master, epel7, f24] was unorphaned by raphgro An implementation of the lint program https://admin.fedoraproject.org/pkgdb/package/splint sylpheed [epel7] was unorphaned by sharkcz GTK+ based, lightweight, and fast email client https://admin.fedoraproject.org/pkgdb/package/sylpheed 0 packages were unretired 4 packages were given purple-skypeweb [f23, f22, master] was given by limb to xvitaly Adds support for Skype to libpurple-based clients https://admin.fedoraproject.org/pkgdb/package/purple-skypeweb python-cerberus [master] was given by limb to ignatenkobrain Lightweight, extensible data validation library for Python https://admin.fedoraproject.org/pkgdb/package/python-cerberus python-cloudfiles [f23, f22, el6, master, f24] was given by nb to pwalter Python language bindings for Rackspace CloudFiles API https://admin.fedoraproject.org/pkgdb/package/python-cloudfiles python-volatility [master] was given by alon to rebus Volatile memory extraction utility framework https://admin.fedoraproject.org/pkgdb/package/python-volatility 2 packages had new branches purple-skypeweb had a new branch: f24 for xvitaly by limb Adds support for Skype to libpurple-based clients https://admin.fedoraproject.org/pkgdb/package/purple-skypeweb python-cerberus had a new branch: f24 for ignatenkobrain by limb Lightweight, extensible data validation library for Python https://admin.fedoraproject.org/pkgdb/package/python-cerberus Sources: https://github.com/pypingou/fedora-owner-change -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: [Modularity] RFC: rebuilding components of modules and namespace issues
Dne 20.6.2016 v 15:14 Karsten Hopp napsal(a): > > Copy doesn't allow multiple builds with the same N-V-R either according to > this: > https://fedorahosted.org/copr/wiki/UserDocs#WhathappenswhenItrytobuildapackagewiththesameversionnumber Yes. But you can have the same NEVRA in different project (even of the same user). While in Koji you cannot have the same NEVRA in different tag. And you cannot have it in whole Koji instance. > I also couldn't find any information about defining your own build > environments in copr. I know that in koji privileged > users can set up their own tag with exactly those package tagged in there > that they need (koji-shadow works like this > for example). Does copr allow something similar ? Yes, it allows adding additional packages to chroot. See 2nd and 3rd picture from bottom https://fedorahosted.org/copr/wiki/ScreenshotsTutorial There is no API call for this. Simply because no one wanted it yet. And very soon it will allow defining the package set in buildchroot completely. -- Miroslav Suchy, RHCA Red Hat, Senior Software Engineer, #brno, #devexp, #fedora-buildsys -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
(retire nc6) never retired a package before
Hi all, I've never retired a package before, so I'm trying to figure out my way through it for nc6. Background: * nc was properly obsoleted by nmap-ncat, and retired (though, it hasn't been removed from comps entirely) * nc6 should also be obsoleted by nmap-ncat with nc, but it never was. Instead it was just orphaned, so I took it (before I fully understood the situation). What I'm wondering is: Which branch should I retire this in, and work with nmap packager to add an Obsoletes line for nc6? Just master/rawhide? Or all branches? -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: (retire nc6) never retired a package before
> I've never retired a package before, so I'm trying to figure out my way > through it for nc6. > > Background: > > * nc was properly obsoleted by nmap-ncat, and retired (though, it hasn't > been removed from comps entirely) > * nc6 should also be obsoleted by nmap-ncat with nc, but it never was. > Instead it was just orphaned, so I took it (before I fully understood the > situation). > > What I'm wondering is: > > Which branch should I retire this in, and work with nmap packager to add an > Obsoletes line for nc6? Just master/rawhide? Or all branches? So you should add Provides, not just obsoletes to ensure a clean upgrade between releases. Also ensure that any packages have their dependencies to require the replacement, this just looks to be hadoop and qt-virt-manager. On branches, once a release is out you can't block a package, you can push updates to other packages that obsolete/provide it so it's replaced but because the f24 (as an example) is locked it'll always be there, so you should just retire it in rawhide (master in the fedpkg checkout) with a "fedpkg retire 'retirement message details'". Peter -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
[Modularity] Modularity Status Update (June 20, 2016)
Modularity WG Meeting === Reminder! Meeting[1] tomorrow (Jun 21) 15h UTC in #fedora-meeting-3. Agenda[2]. Please add any ideas/questions you may have. [1]: https://apps.fedoraproject.org/calendar/modularity/ [2]: http://piratepad.nl/modularity-wg-agendas Module Building === We have integrated module depsolving using libsolv[1]. We also are now running automated tests on the modulemd. Finally, we have developed some example modules[2] that we will be using as end to end examples and tests of the toolchain. From a documentation perspective, we have also developed some physical architecture notes detailing the implementation of the Infra[4] document discussed in a prior update. [1]: https://pagure.io/fm-modulemd-resolver [2]: https://pagure.io/fm-modules [3]: https://fedoraproject.org/wiki/Modularization/Developer_Notes [4]: https://fedoraproject.org/wiki/Modularization/Infra Flock Deliverable === During this sprint we put a lot of time and energy into fleshing out the outline of the Flock Release[1] into Epics[2] and Stories[3] we can work on. [1]: https://fedoraproject.org/wiki/Modularity_Working_Group/releases/Flock_2016_Release [2]: http://taiga.fedorainfracloud.org/project/modularity-roadmap/ [3]: http://taiga.fedorainfracloud.org/project/modularity/ Demos and Meeting Minutes === Demos Sprint 7: https://www.youtube.com/playlist?list=PLcwHJG45BmANGOBocdSTOC7220A9Fd_vH *Note:* messed up zodbot-fu and gave these minutes the wrong meeting name. Normally, they are under: https://meetbot.fedoraproject.org/sresults/?group_id=modularity_wg&type=team Minutes, June 14, 2016: https://meetbot.fedoraproject.org/teams/weekly_meeting_of_modularity_wg/weekly_meeting_of_modularity_wg.2016-06-14-15.00.html Log, June 14, 2016: https://meetbot.fedoraproject.org/teams/weekly_meeting_of_modularity_wg/weekly_meeting_of_modularity_wg.2016-06-14-15.00.log.html Minutes, June 07, 2016: https://meetbot.fedoraproject.org/teams/modularity_wg/modularity_wg.2016-06-07-15.08.html Log, June 07, 2016: https://meetbot.fedoraproject.org/teams/modularity_wg/modularity_wg.2016-06-07-15.08.log.html -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
[Modularity] Modularity Status Update (June 20, 2016) (fixed from html)
** *Uhh that was weird. * * Modularity WG Meeting === Reminder! Meeting[1] tomorrow (Jun 21) 15h UTC in #fedora-meeting-3. Agenda[2]. Please add any ideas/questions you may have. [1]: https://apps.fedoraproject.org/calendar/modularity/ [2]: http://piratepad.nl/modularity-wg-agendas Module Building === We have integrated module depsolving using libsolv[1]. We also are now running automated tests on the modulemd. Finally, we have developed some example modules[2] that we will be using as end to end examples and tests of the toolchain. From a documentation perspective, we have also developed some physical architecture notes detailing the implementation of the Infra[4] document discussed in a prior update. [1]: https://pagure.io/fm-modulemd-resolver [2]: https://pagure.io/fm-modules [3]: https://fedoraproject.org/wiki/Modularization/Developer_Notes [4]: https://fedoraproject.org/wiki/Modularization/Infra Flock Deliverable === During this sprint we put a lot of time and energy into fleshing out the outline of the Flock Release[1] into Epics[2] and Stories[3] we can work on. [1]: https://fedoraproject.org/wiki/Modularity_Working_Group/releases/Flock_2016_Release [2]: http://taiga.fedorainfracloud.org/project/modularity-roadmap/ [3]: http://taiga.fedorainfracloud.org/project/modularity/ Demos and Meeting Minutes === Demos Sprint 7: https://www.youtube.com/playlist?list=PLcwHJG45BmANGOBocdSTOC7220A9Fd_vH *Note:* messed up zodbot-fu and gave these minutes the wrong meeting name. Normally, they are under: https://meetbot.fedoraproject.org/sresults/?group_id=modularity_wg&type=team Minutes, June 14, 2016: https://meetbot.fedoraproject.org/teams/weekly_meeting_of_modularity_wg/weekly_meeting_of_modularity_wg.2016-06-14-15.00.html Log, June 14, 2016: https://meetbot.fedoraproject.org/teams/weekly_meeting_of_modularity_wg/weekly_meeting_of_modularity_wg.2016-06-14-15.00.log.html Minutes, June 07, 2016: https://meetbot.fedoraproject.org/teams/modularity_wg/modularity_wg.2016-06-07-15.08.html Log, June 07, 2016: https://meetbot.fedoraproject.org/teams/modularity_wg/modularity_wg.2016-06-07-15.08.log.html * -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: (retire nc6) never retired a package before
On Mon, Jun 20, 2016 at 5:02 PM Peter Robinson wrote: > > I've never retired a package before, so I'm trying to figure out my way > > through it for nc6. > > > > Background: > > > > * nc was properly obsoleted by nmap-ncat, and retired (though, it > hasn't > > been removed from comps entirely) > > * nc6 should also be obsoleted by nmap-ncat with nc, but it never was. > > Instead it was just orphaned, so I took it (before I fully understood the > > situation). > > > > What I'm wondering is: > > > > Which branch should I retire this in, and work with nmap packager to add > an > > Obsoletes line for nc6? Just master/rawhide? Or all branches? > > So you should add Provides, not just obsoletes to ensure a clean > upgrade between releases. Also ensure that any packages have their > dependencies to require the replacement, this just looks to be hadoop > and qt-virt-manager. > > Thanks. I'll file a bug with nmap to add Provides/Obsoletes, since I'm not a maintainer on that. I'm working on hadoop, and qt-virt-manager looks like they've already addressed it. > On branches, once a release is out you can't block a package, you can > push updates to other packages that obsolete/provide it so it's > replaced but because the f24 (as an example) is locked it'll always be > there, so you should just retire it in rawhide (master in the fedpkg > checkout) with a "fedpkg retire 'retirement message details'". > > Okay, cool. I've retired the package in rawhide, then. Still need to submit pull request to update comps. -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Unsorted comps
So, I'm trying to follow the retire instructions to retire nc6 and update comps, and I noticed a discrepancy between the instructions for updating the comps, and the actual state of the comps files. Running the xsltproc command at https://fedoraproject.org/wiki/How_to_use_and_edit_comps.xml_for_package_groups always results in a different/re-sorted/de-duplicated version of the comps file. Every version of the file I've checked (f19+) is plagued with duplicates and out-of-order entries. Is this normal? Should somebody just go in and do a quick cleanup of all the files, or is there a reason they are being preserved in a state which doesn't match the instructions on the wiki? -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
"dnf grouplist" does not list all available groups
Hello, I'm using F24_RC-1.2. After a fresh install of the server variant (Fedora-Server-dvd-x86_64-24-1.2.iso), when I try to list all available groups with "dnf grouplist", I do not get all available groups. For example, groups like gnome and virtualization are not listed. However, when I do a "dnf groupinfo virtualization", I do get information about the missing group. Why does "dnf grouplist" not list all available groups? Is there any alternative dnf command to list these "hidden" groups? Output of "dnf grouplist" and "dnf groupinfo virtualization" given below for reference: *** [root@vinu vinu]# dnf grouplist Last metadata expiration check: 0:00:43 ago on Tue Jun 21 06:51:18 2016. Available environment groups: Minimal Install Fedora Custom Operating System Fedora Server Edition Fedora Workstation Fedora Cloud Server Xfce Desktop LXDE Desktop Hawaii Desktop LXQt Desktop Cinnamon Desktop MATE Desktop Sugar Desktop Environment Development and Creative Workstation Web Server Infrastructure Server Basic Desktop Installed environment groups: KDE Plasma Workspaces Installed groups: Administration Tools LibreOffice Available groups: Ansible node Audio Production Authoring and Publishing Books and Guides C Development Tools and Libraries Cloud Infrastructure Cloud Management Tools Container Management D Development Tools and Libraries Design Suite Development Tools Domain Membership Fedora Eclipse Editors Educational Software Electronic Lab Engineering and Scientific FreeIPA Server Games and Entertainment Headless Management MATE Applications MATE Compiz Medical Applications Milkymist Network Servers Office/Productivity Robotics RPM Development Tools Security Lab Sound and Video System Tools Text-based Internet 3D Printing Window Managers [root@vinu vinu]# [root@vinu vinu]# dnf groupinfo Virtualization Last metadata expiration check: 0:02:51 ago on Tue Jun 21 06:51:18 2016. Group: Virtualization Description: These packages provide a graphical virtualization environment. Mandatory Packages: virt-install Default Packages: libvirt-daemon-config-network libvirt-daemon-kvm qemu-kvm virt-manager virt-viewer Optional Packages: guestfs-browser libguestfs-tools python-libguestfs virt-top [root@vinu vinu]# -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
[Fedocal] Reminder meeting : Modularity WG
Dear all, You are kindly invited to the meeting: Modularity WG on 2016-06-21 from 15:00:00 to 16:00:00 UTC At fedora-meetin...@irc.freenode.net The meeting will be about: Meeting for the Modularity Working Group. More information available at: [Modularity Working Group wiki page](https://fedoraproject.org/wiki/Modularity_Working_Group) The agenda for the meeting is available at [modularity-wg-agendas pad](http://piratepad.nl/modularity-wg-agendas). Source: https://apps.fedoraproject.org/calendar/meeting/3924/ -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: "dnf grouplist" does not list all available groups
On Tue, 2016-06-21 at 01:30 +, Vinu Moses wrote: > Hello, > > I'm using F24_RC-1.2. After a fresh install of the server variant > (Fedora-Server-dvd-x86_64-24-1.2.iso), when I try to list all > available groups with "dnf grouplist", I do not get all available > groups. For example, groups like gnome and virtualization are not > listed. However, when I do a "dnf groupinfo virtualization", I do get > information about the missing group. > > Why does "dnf grouplist" not list all available groups? It's by design. In comps, groups can be marked 'user visible' true or false. Ones that are not 'user visible' do not appear in anaconda's UI or in a simple 'dnf grouplist'... > Is there any alternative dnf command to list these "hidden" groups? ...well. Er. I think there used to be for yum. I'm not so sure there is for dnf, I poked around a bit but can't find anything. You can see them by looking in the comps repo, though: https://pagure.io/fedora-comps -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
Re: "dnf grouplist" does not list all available groups
> Is there any alternative dnf command to list these "hidden" groups? "dnf grouplist hidden" works as in yum. But it seems undocumented. /Lef -- devel mailing list devel@lists.fedoraproject.org https://lists.fedoraproject.org/admin/lists/devel@lists.fedoraproject.org
