Re: Orphaned packages looking for new maintainers (see note about xinetd)
On Wednesday, November 11, 2020 4:51:47 AM EST Petr Pisar wrote: > I believe it's unlikely that somobody will adopt xinetd. It was orphaned > because its maintainer orphaned all his packages. Xinetd is needed because it does the poly-instantiated network connection when Linux is used for MLS systems. I suppose this could be coded into systemd. But systemd has always advertised itself as not replacing Xinetd and all its features. So, I don't know how that might go. -Steve ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Orphaned packages looking for new maintainers (see note about xinetd)
On Wed, Nov 11, 2020 at 5:40 PM Wolfgang Ulbrich wrote: > I know where my package are listed at > https://src.fedoraproject.org/dashboard/projects :) > But... > [root@mother rave]# dnf repoquery --whatrequires sgpio > Letzte Prüfung auf abgelaufene Metadaten: vor 1:28:41 am Mi 11 Nov 2020 > 17:04:25 CET. > [root@mother rave]# dnf repoquery --whatrequires sgpio > Letzte Prüfung auf abgelaufene Metadaten: vor 1:28:41 am Mi 11 Nov 2020 > 17:04:25 CET. > dmraid-devel-0:1.0.0.rc16-44.fc32.x86_64 > dmraid-events-0:1.0.0.rc16-44.fc32.x86_64-devel-0:1.0.0.rc16-44.fc32.x86_64 > dmraid-events-0:1.0.0.rc16-44.fc32.x86_64 > > Hmm, i do not maintain dmraid or any package which depends on dmraid > > [root@mother rave]# dnf repoquery --whatrequires dmraid > Letzte Prüfung auf abgelaufene Metadaten: vor 1:30:20 am Mi 11 Nov 2020 > 17:04:25 CET. > dmraid-devel-0:1.0.0.rc16-44.fc32.x86_64 > dmraid-events-0:1.0.0.rc16-44.fc32.x86_64 > libblockdev-dm-0:2.23-2.fc32.i686 > libblockdev-dm-0:2.23-2.fc32.x86_64 > libblockdev-dm-0:2.24-2.fc32.i686 > libblockdev-dm-0:2.24-2.fc32.x86_64 > [root@mother rave]# dnf repoquery --whatrequires libblockdev-dm > Letzte Prüfung auf abgelaufene Metadaten: vor 1:30:52 am Mi 11 Nov 2020 > 17:04:25 CET. > libblockdev-dm-devel-0:2.23-2.fc32.i686 > libblockdev-dm-devel-0:2.23-2.fc32.x86_64 > libblockdev-dm-devel-0:2.24-2.fc32.i686 > libblockdev-dm-devel-0:2.24-2.fc32.x86_64 > libblockdev-plugins-all-0:2.23-2.fc32.x86_64 > libblockdev-plugins-all-0:2.24-2.fc32.x86_64 > [root@mother rave]# dnf repoquery --whatrequires libblockdev-plugins-all > Letzte Prüfung auf abgelaufene Metadaten: vor 1:31:26 am Mi 11 Nov 2020 > 17:04:25 CET. > anaconda-install-env-deps-0:32.24.7-1.fc32.x86_64 > anaconda-install-env-deps-0:32.24.7-2.fc32.x86_64 > > And caja doesn't depend on any of them. > The packager dashboard has this in a nice graph that shows the dependency tree: caja -> gvfs -> udisks2 -> libblockdev -> dmraid -> sgpio -Ian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Orphaned packages looking for new maintainers (see note about xinetd)
I know where my package are listed at https://src.fedoraproject.org/dashboard/projects :) But... [root@mother rave]# dnf repoquery --whatrequires sgpio Letzte Prüfung auf abgelaufene Metadaten: vor 1:28:41 am Mi 11 Nov 2020 17:04:25 CET. [root@mother rave]# dnf repoquery --whatrequires sgpio Letzte Prüfung auf abgelaufene Metadaten: vor 1:28:41 am Mi 11 Nov 2020 17:04:25 CET. dmraid-devel-0:1.0.0.rc16-44.fc32.x86_64 dmraid-events-0:1.0.0.rc16-44.fc32.x86_64-devel-0:1.0.0.rc16-44.fc32.x86_64 dmraid-events-0:1.0.0.rc16-44.fc32.x86_64 Hmm, i do not maintain dmraid or any package which depends on dmraid [root@mother rave]# dnf repoquery --whatrequires dmraid Letzte Prüfung auf abgelaufene Metadaten: vor 1:30:20 am Mi 11 Nov 2020 17:04:25 CET. dmraid-devel-0:1.0.0.rc16-44.fc32.x86_64 dmraid-events-0:1.0.0.rc16-44.fc32.x86_64 libblockdev-dm-0:2.23-2.fc32.i686 libblockdev-dm-0:2.23-2.fc32.x86_64 libblockdev-dm-0:2.24-2.fc32.i686 libblockdev-dm-0:2.24-2.fc32.x86_64 [root@mother rave]# dnf repoquery --whatrequires libblockdev-dm Letzte Prüfung auf abgelaufene Metadaten: vor 1:30:52 am Mi 11 Nov 2020 17:04:25 CET. libblockdev-dm-devel-0:2.23-2.fc32.i686 libblockdev-dm-devel-0:2.23-2.fc32.x86_64 libblockdev-dm-devel-0:2.24-2.fc32.i686 libblockdev-dm-devel-0:2.24-2.fc32.x86_64 libblockdev-plugins-all-0:2.23-2.fc32.x86_64 libblockdev-plugins-all-0:2.24-2.fc32.x86_64 [root@mother rave]# dnf repoquery --whatrequires libblockdev-plugins-all Letzte Prüfung auf abgelaufene Metadaten: vor 1:31:26 am Mi 11 Nov 2020 17:04:25 CET. anaconda-install-env-deps-0:32.24.7-1.fc32.x86_64 anaconda-install-env-deps-0:32.24.7-2.fc32.x86_64 And caja doesn't depend on any of them. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Orphaned packages looking for new maintainers (see note about xinetd)
On Wed, Nov 11, 2020 at 3:01 PM Chris Adams wrote: > Are there replacements for the old services built in to xinetd? Not that I know of as being integrated, although writing such servers (often in perl) can often be seen in training materials about network socket programming in a few dozen lines of code. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Orphaned packages looking for new maintainers (see note about xinetd)
On Wed, 11 Nov 2020 at 10:01, Chris Adams wrote: > Once upon a time, Petr Pisar said: > > I believe it's unlikely that somobody will adopt xinetd. It was orphaned > > because its maintainer orphaned all his packages. > > Are there replacements for the old services built in to xinetd? It's a > surprise, but there are still network devices for service provider > networks that want to use time and/or daytime to set their clocks at > boot (so $DAYJOB still has to provision servers with those services > enabled on private networks occasionally). > > Yes, I know it is 2020, and all about NTP and such... but I don't write > the firmware in those devices. If you haven't worked on service > provider stuff before... it is VERY slow to change. > > I expect that the only way to make it work will be having an EL7 system til 2024 and then an eventual giant hardware firesale in 2030 or so. Daytime/time have only worked by the 'grace' of Fortuna since probably the late 1990's, and not tested except for those people who actually have to deal with said hardware since then. Eventually the technology hits a wall like it does every 5 to 10 years and a mass amount of stuff has to be 'retired'.. This usually happens after a crisis like a recession, a CFO/CIO retiring, or some set of sysadmins who kept it working are fully retired (aka it is now too expensive to pay for them being after-job consultants so their contracts are ended.) > -- > Chris Adams > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > -- 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Orphaned packages looking for new maintainers (see note about xinetd)
Once upon a time, Petr Pisar said: > I believe it's unlikely that somobody will adopt xinetd. It was orphaned > because its maintainer orphaned all his packages. Are there replacements for the old services built in to xinetd? It's a surprise, but there are still network devices for service provider networks that want to use time and/or daytime to set their clocks at boot (so $DAYJOB still has to provision servers with those services enabled on private networks occasionally). Yes, I know it is 2020, and all about NTP and such... but I don't write the firmware in those devices. If you haven't worked on service provider stuff before... it is VERY slow to change. -- Chris Adams ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Orphaned packages looking for new maintainers (see note about xinetd)
On Mon, Nov 02, 2020 at 11:25:39AM -, Michael J Gruber wrote: > > = NOTE about xinetd = > > > > Many packagers are listed as affected by xinetd. The dependency chain is: > > > > cvs (kasal, ppisar) > > cvs-inetd.noarch requires xinetd > > > > git (amahdal, besser82, chrisw, pcahyna, pstodulk, skisela, tmz) > > git.src requires cvs > > git-cvs.noarch requires cvs > > > > ( ) > > requires git > > > > Note that if xinetd indeed goes away, your package will most likely not be > > affected, unless you actually need git-cvs. > > > > = end NOTE = > > Also, git requires only the client functionality, not cvs-inetd itself. So > it would be good to get input from the former xinetd maintainer whether > - xinetd should be retired fro some reason (and cvs should retire the > cvs-inetd subpackage) > - or xinetd should simply be picked up. > I removed the cvs-inted subpackage from Fedora 34. Those who need to run a CVS server can use systemd cvs@.service activated by cvs.socket instead. I believe it's unlikely that somobody will adopt xinetd. It was orphaned because its maintainer orphaned all his packages. -- Petr signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: git -> cvs (was: Re: Orphaned packages looking for new maintainers (see note about xinetd))
Hi, Ian McInerney wrote: > Why not split the cvs package like git and create a cvs-core package that > actually contains the cvs executables/files and then only BR/require that > from git/git-cvs? That would be the more immediate solution that prunes the > affected packages from the xinetd orphaning by quite a lot. The cvs package _is_ split up. Git doesn't BR cvs-inetd or anything. The reason this dep chain is in the list is because *iff* xinetd were to be removed (without cvs dropping the BR), then cvs would be removed, taking git along with it (if git did not drop its cvs BR). That's certainly _not_ going to happen though. ;) I don't think there's much doubt about the ease of a fix, should one be required. If xinetd goes away, cvs can simply drop the inetd subpackage. But someone may pick up xinetd and make that moot. Failing either of those outcomes, git can drop its cvs BR & subpackage easily. -- Todd signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: git -> cvs (was: Re: Orphaned packages looking for new maintainers (see note about xinetd))
On Mon, 2020-11-09 at 21:14 +, Gary Buhrmaster wrote: > On Mon, Nov 9, 2020 at 9:04 PM Sérgio Basto > wrote: > > > Like tftp we may replace xinetd by systemd service files [1] , > > if we replace cvs-inetd by a systemd service, the problem is > > solved. > > I am pretty sure cvs already ships systemd service files. > > The issue is that there is also a sub-package built that > requires xinetd (cvs-inetd?). > > So, if my belief is correct, this can be easily resolved > by no longer building/shipping the cvs-inetd subpackage > (at least for Fedora). exactly > ___ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: > https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org -- Sérgio M. B. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: git -> cvs (was: Re: Orphaned packages looking for new maintainers (see note about xinetd))
On Mon, Nov 9, 2020 at 9:32 PM Todd Zullinger wrote: > Hi, > > Sérgio Basto wrote: > > Like tftp we may replace xinetd by systemd service files [1] , > > if we replace cvs-inetd by a systemd service, the problem is solved. > > > > [1] > > > https://src.fedoraproject.org/rpms/tftp/c/15a26fcde8a0078766b6bbba183d89f920e51535?branch=master > > The cvs package has supported systemd for years. There is > simply an inetd subpackage which provides support for xinetd > still. > > If xinetd is left orpahaned and retired, dropping the inetd > subpackage from cvs might look something like: > > https://src.fedoraproject.org/fork/tmz/rpms/cvs/c/ee901571db > > I didn't file that as PR yet because it's not clear whether > xinetd will be adopted or not. > > But it should be relatively easy for us (in the sense of > most any interested packager) to remove the xinetd dep from > cvs. > > -- > Todd > > Why not split the cvs package like git and create a cvs-core package that actually contains the cvs executables/files and then only BR/require that from git/git-cvs? That would be the more immediate solution that prunes the affected packages from the xinetd orphaning by quite a lot. -Ian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: git -> cvs (was: Re: Orphaned packages looking for new maintainers (see note about xinetd))
Hi, Sérgio Basto wrote: > Like tftp we may replace xinetd by systemd service files [1] , > if we replace cvs-inetd by a systemd service, the problem is solved. > > [1] > https://src.fedoraproject.org/rpms/tftp/c/15a26fcde8a0078766b6bbba183d89f920e51535?branch=master The cvs package has supported systemd for years. There is simply an inetd subpackage which provides support for xinetd still. If xinetd is left orpahaned and retired, dropping the inetd subpackage from cvs might look something like: https://src.fedoraproject.org/fork/tmz/rpms/cvs/c/ee901571db I didn't file that as PR yet because it's not clear whether xinetd will be adopted or not. But it should be relatively easy for us (in the sense of most any interested packager) to remove the xinetd dep from cvs. -- Todd signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: git -> cvs (was: Re: Orphaned packages looking for new maintainers (see note about xinetd))
On Mon, Nov 9, 2020 at 9:04 PM Sérgio Basto wrote: > Like tftp we may replace xinetd by systemd service files [1] , > if we replace cvs-inetd by a systemd service, the problem is solved. I am pretty sure cvs already ships systemd service files. The issue is that there is also a sub-package built that requires xinetd (cvs-inetd?). So, if my belief is correct, this can be easily resolved by no longer building/shipping the cvs-inetd subpackage (at least for Fedora). ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: git -> cvs (was: Re: Orphaned packages looking for new maintainers (see note about xinetd))
On Mon, 2020-11-09 at 16:59 +, Richard W.M. Jones wrote:
> On Mon, Nov 09, 2020 at 11:50:06AM -0500, Todd Zullinger wrote:
> > Hi,
> >
> > Richard W.M. Jones wrote:
> > > On Mon, Nov 09, 2020 at 11:17:38AM -0500, Todd Zullinger wrote:
> > > > The cvs and cvsps BR's are for the test suite, since we
> > > > prefer to use the comprehensive test suite that git
> > > > includes. So dropping those BR's is not a useful option.
> > >
> > > The test suite still ran, and the subpackage still got built.
> > >
> > > However in the test suite the cvsimport tests were skipped:
> > >
> > > t9600-cvsimport.sh . skipped:
> > > skipping cvsimport
> > > tests, cvs not found
> > > t9601-cvsimport-vendor-branch.sh ... skipped:
> > > skipping cvsimport
> > > tests, cvs not found
> > > t9602-cvsimport-branches-tags.sh ... skipped:
> > > skipping cvsimport
> > > tests, cvs not found
> > > t9603-cvsimport-patchsets.sh ... skipped:
> > > skipping cvsimport
> > > tests, cvs not found
> > > t9604-cvsimport-timestamps.sh .. skipped:
> > > skipping cvsimport
> > > tests, cvs not found
> >
> > Yep, exactly. If we simply removed the BR's, we'd just be
> > shipping a subpackage with commands that weren't tested and
> > wouldn't work without cvs. Not a good user-experience. :)
>
> Sure, I agree :-)
Like tftp we may replace xinetd by systemd service files [1] ,
if we replace cvs-inetd by a systemd service, the problem is solved.
[1]
https://src.fedoraproject.org/rpms/tftp/c/15a26fcde8a0078766b6bbba183d89f920e51535?branch=master
> Rich.
>
> > I'll keep my eye on the progress of removing the xinetd
> > dependency from cvs and will be sure to disable cvs in git
> > if that doesn't happen for some reason. Hopefully it
> > doesn't come to that.
> >
> > In that case, a change like this should be all we need:
> >
> > diff --git i/git.spec w/git.spec
> > index 5188290..e85363b 100644
> > --- i/git.spec
> > +++ w/git.spec
> > @@ -66,8 +66,8 @@
> > %endif
> >
> > # Allow cvs subpackage to be toggled via --with/--without
> > -# Disable cvs subpackage by default on EL > 7
> > -%if 0%{?rhel} > 7
> > +# Disable cvs subpackage by default on Fedora >= 34 and EL > 7
> > +%if 0%{?fedora} >= 34 || 0%{?rhel} > 7
> > %bcond_with cvs
> > %else
> > %bcond_without cvs
> >
> > --
> > Todd
>
>
> --
> Richard Jones, Virtualization Group, Red Hat
> http://people.redhat.com/~rjones
> Read my programming and virtualization blog:
> http://rwmj.wordpress.com
> virt-top is 'top' for virtual machines. Tiny program with many
> powerful monitoring features, net stats, disk stats, logging, etc.
> http://people.redhat.com/~rjones/virt-top
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines:
> https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
--
Sérgio M. B.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: git -> cvs (was: Re: Orphaned packages looking for new maintainers (see note about xinetd))
On Mon, Nov 09, 2020 at 11:50:06AM -0500, Todd Zullinger wrote:
> Hi,
>
> Richard W.M. Jones wrote:
> > On Mon, Nov 09, 2020 at 11:17:38AM -0500, Todd Zullinger wrote:
> >> The cvs and cvsps BR's are for the test suite, since we
> >> prefer to use the comprehensive test suite that git
> >> includes. So dropping those BR's is not a useful option.
> >
> > The test suite still ran, and the subpackage still got built.
> >
> > However in the test suite the cvsimport tests were skipped:
> >
> > t9600-cvsimport.sh . skipped: skipping
> > cvsimport
> > tests, cvs not found
> > t9601-cvsimport-vendor-branch.sh ... skipped: skipping
> > cvsimport
> > tests, cvs not found
> > t9602-cvsimport-branches-tags.sh ... skipped: skipping
> > cvsimport
> > tests, cvs not found
> > t9603-cvsimport-patchsets.sh ... skipped: skipping
> > cvsimport
> > tests, cvs not found
> > t9604-cvsimport-timestamps.sh .. skipped: skipping
> > cvsimport
> > tests, cvs not found
>
> Yep, exactly. If we simply removed the BR's, we'd just be
> shipping a subpackage with commands that weren't tested and
> wouldn't work without cvs. Not a good user-experience. :)
Sure, I agree :-)
Rich.
> I'll keep my eye on the progress of removing the xinetd
> dependency from cvs and will be sure to disable cvs in git
> if that doesn't happen for some reason. Hopefully it
> doesn't come to that.
>
> In that case, a change like this should be all we need:
>
> diff --git i/git.spec w/git.spec
> index 5188290..e85363b 100644
> --- i/git.spec
> +++ w/git.spec
> @@ -66,8 +66,8 @@
> %endif
>
> # Allow cvs subpackage to be toggled via --with/--without
> -# Disable cvs subpackage by default on EL > 7
> -%if 0%{?rhel} > 7
> +# Disable cvs subpackage by default on Fedora >= 34 and EL > 7
> +%if 0%{?fedora} >= 34 || 0%{?rhel} > 7
> %bcond_with cvs
> %else
> %bcond_without cvs
>
> --
> Todd
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines. Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Orphaned packages looking for new maintainers (see note about xinetd)
On Mon, Nov 09, 2020 at 04:46:39PM +, Sven Kieske wrote: > On Mo, 2020-11-09 at 14:10 +0100, Robert-André Mauchin wrote: > > On Monday, 9 November 2020 12:09:00 CET you wrote: > > > numad orphan 1 weeks > > > ago > > > > Any maintainer of libvirt interested in taking this or breaking the > > dependency > > link? > > the old maintainer who orphaned this > seemed also to be the sole upstream maintainer. > > no commits since over 2 years in the upstream repo: > > https://pagure.io/numad/commits/master > > I don't know if this is really "finished" software, but > this is a rather central piece of software for larger data center > workloads, imho. It is largely obsolete as kernel autonuma is preferred in most cases. If and when it is removed from Fedora, we'll drop the dep from libvirt. 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: git -> cvs (was: Re: Orphaned packages looking for new maintainers (see note about xinetd))
Hi,
Richard W.M. Jones wrote:
> On Mon, Nov 09, 2020 at 11:17:38AM -0500, Todd Zullinger wrote:
>> The cvs and cvsps BR's are for the test suite, since we
>> prefer to use the comprehensive test suite that git
>> includes. So dropping those BR's is not a useful option.
>
> The test suite still ran, and the subpackage still got built.
>
> However in the test suite the cvsimport tests were skipped:
>
> t9600-cvsimport.sh . skipped: skipping
> cvsimport
> tests, cvs not found
> t9601-cvsimport-vendor-branch.sh ... skipped: skipping
> cvsimport
> tests, cvs not found
> t9602-cvsimport-branches-tags.sh ... skipped: skipping
> cvsimport
> tests, cvs not found
> t9603-cvsimport-patchsets.sh ... skipped: skipping
> cvsimport
> tests, cvs not found
> t9604-cvsimport-timestamps.sh .. skipped: skipping
> cvsimport
> tests, cvs not found
Yep, exactly. If we simply removed the BR's, we'd just be
shipping a subpackage with commands that weren't tested and
wouldn't work without cvs. Not a good user-experience. :)
I'll keep my eye on the progress of removing the xinetd
dependency from cvs and will be sure to disable cvs in git
if that doesn't happen for some reason. Hopefully it
doesn't come to that.
In that case, a change like this should be all we need:
diff --git i/git.spec w/git.spec
index 5188290..e85363b 100644
--- i/git.spec
+++ w/git.spec
@@ -66,8 +66,8 @@
%endif
# Allow cvs subpackage to be toggled via --with/--without
-# Disable cvs subpackage by default on EL > 7
-%if 0%{?rhel} > 7
+# Disable cvs subpackage by default on Fedora >= 34 and EL > 7
+%if 0%{?fedora} >= 34 || 0%{?rhel} > 7
%bcond_with cvs
%else
%bcond_without cvs
--
Todd
signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Orphaned packages looking for new maintainers (see note about xinetd)
On Mo, 2020-11-09 at 14:10 +0100, Robert-André Mauchin wrote: > On Monday, 9 November 2020 12:09:00 CET you wrote: > > numad orphan 1 weeks > > ago > > Any maintainer of libvirt interested in taking this or breaking the > dependency > link? the old maintainer who orphaned this seemed also to be the sole upstream maintainer. no commits since over 2 years in the upstream repo: https://pagure.io/numad/commits/master I don't know if this is really "finished" software, but this is a rather central piece of software for larger data center workloads, imho. -- Mit freundlichen Grüßen / Regards Sven Kieske Systementwickler Mittwald CM Service GmbH & Co. KG Königsberger Straße 4-6 32339 Espelkamp Tel.: 05772 / 293-900 Fax: 05772 / 293-333 https://www.mittwald.de Geschäftsführer: Robert Meyer, Florian Jürgens St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen Informationen zur Datenverarbeitung im Rahmen unserer Geschäftstätigkeit gemäß Art. 13-14 DSGVO sind unter www.mittwald.de/ds abrufbar. signature.asc Description: This is a digitally signed message part ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: git -> cvs (was: Re: Orphaned packages looking for new maintainers (see note about xinetd))
On Mon, Nov 09, 2020 at 11:17:38AM -0500, Todd Zullinger wrote: > Hi, > > Richard W.M. Jones wrote: > > On Mon, Nov 09, 2020 at 12:09:00PM +0100, Miro Hrončok wrote: > >> rjones: xinetd, numad > > > > Your "packager dashboard"[1] which I found for the first time today is > > very useful! > > > > Turns out the problem for my package is this weird ol' dependency chain: > > > > coccinelle -> git -> cvs -> xinetd > > > > Well the first part of that is understandable, because Cocci uses git > > to apply patches (ie. autosetup -S git). > > > > cvs -> xinetd is sort of understandable too. > > > > git -> cvs however(!) It turns out that git has a cvs import > > subpackage. But I wonder if git actually needs cvs around at build > > time to create this? I commented out the BR: cvs, cvsps lines in the > > spec file and it built a cvs import subpackage just fine for me. > > The cvs and cvsps BR's are for the test suite, since we > prefer to use the comprehensive test suite that git > includes. So dropping those BR's is not a useful option. The test suite still ran, and the subpackage still got built. However in the test suite the cvsimport tests were skipped: t9600-cvsimport.sh . skipped: skipping cvsimport tests, cvs not found t9601-cvsimport-vendor-branch.sh ... skipped: skipping cvsimport tests, cvs not found t9602-cvsimport-branches-tags.sh ... skipped: skipping cvsimport tests, cvs not found t9603-cvsimport-patchsets.sh ... skipped: skipping cvsimport tests, cvs not found t9604-cvsimport-timestamps.sh .. skipped: skipping cvsimport tests, cvs not found > Either cvs will drop it's dependency on xinetd and this > problem will be moot or it won't and cvs will be removed > from Fedora. In the latter case, having git ship the > git-cvs subpackage would be silly. > > If cvs gets dropped, we'll likely drop the git-cvs > subpackage entirely (as was done for EL8 -- we have a > %bcond_with/%bcond_without cvs in place already). > > I expect that the xinetd dep in cvs will be removed, but if > it turns out no one cares about cvs and that doesn't happen, > removing the cvs dep from git will be trivial enough. Sure. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-df lists disk usage of guests without needing to install any software inside the virtual machine. Supports Linux and Windows. http://people.redhat.com/~rjones/virt-df/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: git -> cvs (was: Re: Orphaned packages looking for new maintainers (see note about xinetd))
Hi, Richard W.M. Jones wrote: > On Mon, Nov 09, 2020 at 12:09:00PM +0100, Miro Hrončok wrote: >> rjones: xinetd, numad > > Your "packager dashboard"[1] which I found for the first time today is > very useful! > > Turns out the problem for my package is this weird ol' dependency chain: > > coccinelle -> git -> cvs -> xinetd > > Well the first part of that is understandable, because Cocci uses git > to apply patches (ie. autosetup -S git). > > cvs -> xinetd is sort of understandable too. > > git -> cvs however(!) It turns out that git has a cvs import > subpackage. But I wonder if git actually needs cvs around at build > time to create this? I commented out the BR: cvs, cvsps lines in the > spec file and it built a cvs import subpackage just fine for me. The cvs and cvsps BR's are for the test suite, since we prefer to use the comprehensive test suite that git includes. So dropping those BR's is not a useful option. Either cvs will drop it's dependency on xinetd and this problem will be moot or it won't and cvs will be removed from Fedora. In the latter case, having git ship the git-cvs subpackage would be silly. If cvs gets dropped, we'll likely drop the git-cvs subpackage entirely (as was done for EL8 -- we have a %bcond_with/%bcond_without cvs in place already). I expect that the xinetd dep in cvs will be removed, but if it turns out no one cares about cvs and that doesn't happen, removing the cvs dep from git will be trivial enough. -- Todd signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Orphaned packages looking for new maintainers (see note about xinetd)
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. Request package ownership via the *Take* button in he left column on https://src.fedoraproject.org/rpms/ This report is available at: https://churchyard.fedorapeople.org/orphans-2020-11-09.txt grep it for your FAS username and follow the dependency chain. For human readable dependency chains, see https://packager.fedorainfracloud.org/ For all orphaned packages, see https://packager.fedorainfracloud.org/orphan Package (co)maintainers Status Change ansible-collection-community- orphan 1 weeks ago general apache-commons-configuration fnasser, mizdebsk, orphan, 4 weeks ago spike celt071 orphan 2 weeks ago checksec orphan 0 weeks ago compat-guile18jskarvad, mlichvar, orphan, 1 weeks ago tkorbar discord-irc orphan 1 weeks ago dnscaporphan 2 weeks ago dynafed andreamanzi, orphan 1 weeks ago elasticdump orphan 1 weeks ago electrum orphan 2 weeks ago fedora-developer-portal orphan 0 weeks ago ghc-pipes-safeorphan 1 weeks ago gtatool orphan 1 weeks ago hsqldb1 lef, orphan 1 weeks ago hub orphan, ralph, sgallagh 5 weeks ago jboss-jsf-2.1-api orphan 4 weeks ago jsonp lef, orphan 1 weeks ago legendsbrowserorphan 1 weeks ago libbind orphan 2 weeks ago metadata-extractor2 cquad, orphan4 weeks ago mingw-gtkglextepienbro, maci, orphan 2 weeks ago mocha nodejs-sig, orphan, patches 1 weeks ago mpir orphan, slaanesh, zaniyah0 weeks ago netty-tcnativeorphan 1 weeks ago neurord neuro-sig, orphan1 weeks ago nodejs-assume nodejs-sig, orphan 1 weeks ago nodejs-block-stream nodejs-sig, orphan, patches 1 weeks ago nodejs-callback-streamorphan 1 weeks ago nodejs-chalk nodejs-sig, orphan, patches 1 weeks ago nodejs-clear-require orphan 1 weeks ago nodejs-co-mocha nodejs-sig, orphan 1 weeks ago nodejs-co-with-promiseorphan 1 weeks ago nodejs-coffee-coverageorphan 1 weeks ago nodejs-conventional-changelog-orphan 1 weeks ago preset-loader nodejs-csv-stringify orphan 1 weeks ago nodejs-debug-fabulous orphan 1 weeks ago nodejs-defaults humaton, nodejs-sig, orphan, 1 weeks ago vjancik nodejs-define-propertyorphan 1 weeks ago nodejs-figuresnodejs-sig, orphan 1 weeks ago nodejs-flush-write-stream orphan 1 weeks ago nodejs-fs-write-stream-atomic nodejs-sig, orphan, vjancik 1 weeks ago nodejs-gaze nodejs-sig, orphan, patches 1 weeks ago nodejs-glob nodejs-sig, orphan, patches 1 weeks ago nodejs-glob-expandorphan 1 weeks ago nodejs-intercept-require orphan 1 weeks ago nodejs-istanbul-lib-reportorphan 1 weeks ago nodejs-istanbul-reports orphan
Re: Orphaned packages looking for new maintainers (see note about xinetd)
On Monday, 9 November 2020 12:09:00 CET you wrote: > numad orphan 1 weeks > ago Any maintainer of libvirt interested in taking this or breaking the dependency link? Best regards, Robert-André ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Orphaned packages looking for new maintainers (see note about xinetd)
On Mon, Nov 9, 2020 at 12:25 PM Wolfgang Ulbrich wrote: > > Affected (co)maintainers (either directly or via packages' dependencies): > > < cut > > > raveit65: sgpio > > I am still wondering why i am listed here as (co)maintainers. > I do not maintain this package. > > Cheers > Wolfgang > It is not saying that you maintain sgpio, but instead is saying that you have a package that has sgpio in its dependency stack somewhere and would be affected if sgpio were to be removed. Looking at the packager dashboard (yours can be seen here: https://packager.fedorainfracloud.org/raveit65), it looks like it is a very indirect dependency of Caja. -Ian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Orphaned packages looking for new maintainers (see note about xinetd)
> Affected (co)maintainers (either directly or via packages' dependencies): < cut > > raveit65: sgpio I am still wondering why i am listed here as (co)maintainers. I do not maintain this package. Cheers Wolfgang ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: git -> cvs (was: Re: Orphaned packages looking for new maintainers (see note about xinetd))
On 11/9/20 12:55 PM, Richard W.M. Jones wrote: Turns out the problem for my package is this weird ol' dependency chain: coccinelle -> git -> cvs -> xinetd Well the first part of that is understandable, because Cocci uses git to apply patches (ie. autosetup -S git). cvs -> xinetd is sort of understandable too. git -> cvs however(!) It turns out that git has a cvs import subpackage. But I wonder if git actually needs cvs around at build time to create this? I commented out the BR: cvs, cvsps lines in the spec file and it built a cvs import subpackage just fine for me. Yes, see this note in the email: = NOTE about xinetd = Many packagers are listed as affected by xinetd. The dependency chain is: cvs (kasal, ppisar) cvs-inetd.noarch requires xinetd git (amahdal, besser82, chrisw, pcahyna, pstodulk, skisela, tmz) git.src requires cvs git-cvs.noarch requires cvs () requires git Note that if xinetd indeed goes away, your package will most likely not be affected, unless you actually need git-cvs or cvs-inetd. Also note that if your package uses git, it might just (Build)Require git-core (or /usr/bin/git) instaed of full blown git package (with dependencies on Perl and Python). = end NOTE = -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
git -> cvs (was: Re: Orphaned packages looking for new maintainers (see note about xinetd))
On Mon, Nov 09, 2020 at 12:09:00PM +0100, Miro Hrončok wrote:
> rjones: xinetd, numad
Your "packager dashboard"[1] which I found for the first time today is
very useful!
Turns out the problem for my package is this weird ol' dependency chain:
coccinelle -> git -> cvs -> xinetd
Well the first part of that is understandable, because Cocci uses git
to apply patches (ie. autosetup -S git).
cvs -> xinetd is sort of understandable too.
git -> cvs however(!) It turns out that git has a cvs import
subpackage. But I wonder if git actually needs cvs around at build
time to create this? I commented out the BR: cvs, cvsps lines in the
spec file and it built a cvs import subpackage just fine for me.
--
diff --git a/git.spec b/git.spec
index 6081678..f3294b6 100644
--- a/git.spec
+++ b/git.spec
@@ -199,8 +199,8 @@ BuildRequires: apr-util-bdb
# endif fedora >= 27
BuildRequires: bash
%if %{with cvs}
-BuildRequires: cvs
-BuildRequires: cvsps
+#BuildRequires: cvs
+#BuildRequires: cvsps
%endif
# endif with cvs
%if %{use_glibc_langpacks}
--
Rich.
[1] https://packager.fedorainfracloud.org/
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines. Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct:
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives:
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Orphaned packages looking for new maintainers (see note about xinetd)
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. Request package ownership via the *Take* button in he left column on https://src.fedoraproject.org/rpms/ This report is available at: https://churchyard.fedorapeople.org/orphans-2020-11-09.txt grep it for your FAS username and follow the dependency chain. For human readable dependency chains, see https://packager.fedorainfracloud.org/ For all orphaned packages, see https://packager.fedorainfracloud.org/orphan Package (co)maintainers Status Change ansible-collection-community- orphan 1 weeks ago general apache-commons-configuration fnasser, mizdebsk, orphan, 4 weeks ago spike celt071 orphan 2 weeks ago checksec orphan 0 weeks ago compat-guile18jskarvad, mlichvar, orphan, 1 weeks ago tkorbar discord-irc orphan 1 weeks ago dnscaporphan 2 weeks ago dynafed andreamanzi, orphan 1 weeks ago elasticdump orphan 1 weeks ago electrum orphan 2 weeks ago fedora-developer-portal orphan 0 weeks ago ghc-pipes-safeorphan 1 weeks ago gtatool orphan 1 weeks ago hsqldb1 lef, orphan 1 weeks ago hub orphan, ralph, sgallagh 5 weeks ago jboss-jsf-2.1-api orphan 4 weeks ago jsonp lef, orphan 1 weeks ago legendsbrowserorphan 1 weeks ago libbind orphan 2 weeks ago metadata-extractor2 cquad, orphan4 weeks ago mingw-gtkglextepienbro, maci, orphan 2 weeks ago mocha nodejs-sig, orphan, patches 1 weeks ago mpir orphan, slaanesh, zaniyah0 weeks ago netty-tcnativeorphan 1 weeks ago neurord neuro-sig, orphan1 weeks ago nodejs-assume nodejs-sig, orphan 1 weeks ago nodejs-block-stream nodejs-sig, orphan, patches 1 weeks ago nodejs-callback-streamorphan 1 weeks ago nodejs-chalk nodejs-sig, orphan, patches 1 weeks ago nodejs-clear-require orphan 1 weeks ago nodejs-co-mocha nodejs-sig, orphan 1 weeks ago nodejs-co-with-promiseorphan 1 weeks ago nodejs-coffee-coverageorphan 1 weeks ago nodejs-conventional-changelog-orphan 1 weeks ago preset-loader nodejs-csv-stringify orphan 1 weeks ago nodejs-debug-fabulous orphan 1 weeks ago nodejs-defaults humaton, nodejs-sig, orphan, 1 weeks ago vjancik nodejs-define-propertyorphan 1 weeks ago nodejs-figuresnodejs-sig, orphan 1 weeks ago nodejs-flush-write-stream orphan 1 weeks ago nodejs-fs-write-stream-atomic nodejs-sig, orphan, vjancik 1 weeks ago nodejs-gaze nodejs-sig, orphan, patches 1 weeks ago nodejs-glob nodejs-sig, orphan, patches 1 weeks ago nodejs-glob-expandorphan 1 weeks ago nodejs-intercept-require orphan 1 weeks ago nodejs-istanbul-lib-reportorphan 1 weeks ago nodejs-istanbul-reports orphan
Re: Orphaned packages looking for new maintainers (see note about xinetd)
Michael J Gruber wrote: >> = NOTE about xinetd = >> >> Many packagers are listed as affected by xinetd. The dependency chain is: >> >> cvs (kasal, ppisar) >> cvs-inetd.noarch requires xinetd >> >> git (amahdal, besser82, chrisw, pcahyna, pstodulk, skisela, tmz) >> git.src requires cvs >> git-cvs.noarch requires cvs >> >> ( ) >> requires git >> >> Note that if xinetd indeed goes away, your package will most likely not be >> affected, unless you actually need git-cvs. >> >> = end NOTE = > > Also, git requires only the client functionality, not cvs-inetd itself. So it > would be good to get input from the former xinetd maintainer whether > - xinetd should be retired fro some reason (and cvs should retire the > cvs-inetd subpackage) > - or xinetd should simply be picked up. > > Thanks for the clear info about the dependency, btw. It would have been easy > to miss otherwise. Indeed, thanks Miro and Michael! _If_ it comes to it, the git package has a conditional for building without CVS. It's trivial to change the default for f34+ and avoid the cvs dep. It seems likely that cvs can drop the inetd subpackage without much trouble though, so it shouldn't come to that. -- Todd signature.asc Description: PGP signature ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Orphaned packages looking for new maintainers (see note about xinetd)
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. Request package ownership via the *Take* button in he left column on https://src.fedoraproject.org/rpms/ This report is available at: https://churchyard.fedorapeople.org/orphans-2020-11-02.txt grep it for your FAS username and follow the dependency chain. For human readable dependency chains, see https://packager.fedorainfracloud.org/ For all orphaned packages, see https://packager.fedorainfracloud.org/orphan Package (co)maintainers Status Change ansible-collection-community- orphan 0 weeks ago general apache-commons-configuration fnasser, mizdebsk, orphan, 3 weeks ago spike celt071 orphan 1 weeks ago compat-guile18jskarvad, mlichvar, orphan, 0 weeks ago tkorbar discord-irc orphan 0 weeks ago dnscaporphan 1 weeks ago dynafed andreamanzi, orphan 0 weeks ago elasticdump orphan 0 weeks ago electrum orphan 1 weeks ago environment-modules orphan 0 weeks ago ghc-pipes-safeorphan 0 weeks ago gtatool orphan 0 weeks ago hsqldb1 lef, orphan 0 weeks ago hub orphan, ralph, sgallagh 4 weeks ago jboss-jsf-2.1-api orphan 3 weeks ago jsonp lef, orphan 0 weeks ago legendsbrowserorphan 0 weeks ago libbind orphan 1 weeks ago metadata-extractor2 cquad, orphan3 weeks ago mingw-gtkglextepienbro, maci, orphan 1 weeks ago mocha nodejs-sig, orphan, patches 0 weeks ago netty-tcnativeorphan 0 weeks ago neurord neuro-sig, orphan0 weeks ago nodejs-assume nodejs-sig, orphan 0 weeks ago nodejs-block-stream nodejs-sig, orphan, patches 0 weeks ago nodejs-callback-streamorphan 0 weeks ago nodejs-chalk nodejs-sig, orphan, patches 0 weeks ago nodejs-clear-require orphan 0 weeks ago nodejs-co-mocha nodejs-sig, orphan 0 weeks ago nodejs-co-with-promiseorphan 0 weeks ago nodejs-coffee-coverageorphan 0 weeks ago nodejs-conventional-changelog-orphan 0 weeks ago preset-loader nodejs-csv-stringify orphan 0 weeks ago nodejs-debug-fabulous orphan 0 weeks ago nodejs-defaults humaton, nodejs-sig, orphan, 0 weeks ago vjancik nodejs-define-propertyorphan 0 weeks ago nodejs-figuresnodejs-sig, orphan 0 weeks ago nodejs-flush-write-stream orphan 0 weeks ago nodejs-fs-write-stream-atomic nodejs-sig, orphan, vjancik 0 weeks ago nodejs-gaze nodejs-sig, orphan, patches 0 weeks ago nodejs-glob nodejs-sig, orphan, patches 0 weeks ago nodejs-glob-expandorphan 0 weeks ago nodejs-intercept-require orphan 0 weeks ago nodejs-istanbul-lib-reportorphan 0 weeks ago nodejs-istanbul-reports orphan 0 weeks ago nodejs-jade nodejs-sig, orphan, patches 0 weeks ago nodejs-multipipe orphan
Re: Orphaned packages looking for new maintainers (see note about xinetd)
On 02/11/2020 12.27, Miro Hrončok wrote: On 11/2/20 12:13 PM, Fabio M. Di Nitto wrote: On 02/11/2020 12.03, 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. Request package ownership via the *Take* button in he left column on https://src.fedoraproject.org/rpms/ This report is available at: https://churchyard.fedorapeople.org/orphans-2020-11-02.txt grep it for your FAS username and follow the dependency chain. For human readable dependency chains, see https://packager.fedorainfracloud.org/ For all orphaned packages, see https://packager.fedorainfracloud.org/orphan fabbione: numad are you sure the script is running correctly? I have never touched numad in my whole life... :) Yes, I am sure. Ok cool thanks :) Fabio ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Orphaned packages looking for new maintainers (see note about xinetd)
On 11/2/20 12:13 PM, Fabio M. Di Nitto wrote: On 02/11/2020 12.03, 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. Request package ownership via the *Take* button in he left column on https://src.fedoraproject.org/rpms/ This report is available at: https://churchyard.fedorapeople.org/orphans-2020-11-02.txt grep it for your FAS username and follow the dependency chain. For human readable dependency chains, see https://packager.fedorainfracloud.org/ For all orphaned packages, see https://packager.fedorainfracloud.org/orphan fabbione: numad are you sure the script is running correctly? I have never touched numad in my whole life... :) Yes, I am sure. See https://packager.fedorainfracloud.org/fabbione There is fence-virt, depends on libvirt, depends on numad. You can "unroll" the fence-virt to see the *Show dependency network* button for a nice visualization. If you prefer text, see https://churchyard.fedorapeople.org/orphans-2020-11-02.txt and grep it for fabbione and than search up. You'll end up with: Depending on: numad (20), status change: 2020-10-29 (0 weeks ago) libvirt (maintained by: berrange, clalance, crobinso, jforbes, laine, libvirt-maint, osier, veillard, virtmaint-sig) libvirt-daemon-6.8.0-3.fc34.x86_64 requires numad = 0.5-33.20150602git.fc34 libvirt-daemon-qemu-6.8.0-3.fc34.x86_64 requires qemu = 2:5.1.0-6.fc34 fence-virt (maintained by: fabbione, lon, oalbrigt, rmccabe) fence-virtd-libvirt-1.0.0-3.fc33.x86_64 requires libvirt = 6.8.0-3.fc34 fence-virtd-serial-1.0.0-3.fc33.x86_64 requires libvirt = 6.8.0-3.fc34 Hope that helps. -- Miro Hrončok -- Phone: +420777974800 IRC: mhroncok ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Orphaned packages looking for new maintainers (see note about xinetd)
> = NOTE about xinetd = > > Many packagers are listed as affected by xinetd. The dependency chain is: > > cvs (kasal, ppisar) > cvs-inetd.noarch requires xinetd > > git (amahdal, besser82, chrisw, pcahyna, pstodulk, skisela, tmz) > git.src requires cvs > git-cvs.noarch requires cvs > >( ) >requires git > > Note that if xinetd indeed goes away, your package will most likely not be > affected, unless you actually need git-cvs. > > = end NOTE = Also, git requires only the client functionality, not cvs-inetd itself. So it would be good to get input from the former xinetd maintainer whether - xinetd should be retired fro some reason (and cvs should retire the cvs-inetd subpackage) - or xinetd should simply be picked up. Thanks for the clear info about the dependency, btw. It would have been easy to miss otherwise. ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Orphaned packages looking for new maintainers (see note about xinetd)
On Mon, Nov 02, 2020 at 12:13:18PM +0100, Fabio M. Di Nitto wrote: > On 02/11/2020 12.03, 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. > > > > Request package ownership via the *Take* button in he left column on > > https://src.fedoraproject.org/rpms/ > > > > This report is available at: > > https://churchyard.fedorapeople.org/orphans-2020-11-02.txt > > grep it for your FAS username and follow the dependency chain. > > > > For human readable dependency chains, see > > https://packager.fedorainfracloud.org/ > > For all orphaned packages, see https://packager.fedorainfracloud.org/orphan > > > > > fabbione: numad > > are you sure the script is running correctly? > > I have never touched numad in my whole life... :) It isn't saying that you have. This is a list of maintainers whose own packages have a dependancy on numad, and so would get a broken deps if numad was removed. 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://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Re: Orphaned packages looking for new maintainers (see note about xinetd)
On 02/11/2020 12.03, 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. Request package ownership via the *Take* button in he left column on https://src.fedoraproject.org/rpms/ This report is available at: https://churchyard.fedorapeople.org/orphans-2020-11-02.txt grep it for your FAS username and follow the dependency chain. For human readable dependency chains, see https://packager.fedorainfracloud.org/ For all orphaned packages, see https://packager.fedorainfracloud.org/orphan fabbione: numad are you sure the script is running correctly? I have never touched numad in my whole life... :) Fabio ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Orphaned packages looking for new maintainers (see note about xinetd)
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. Request package ownership via the *Take* button in he left column on https://src.fedoraproject.org/rpms/ This report is available at: https://churchyard.fedorapeople.org/orphans-2020-11-02.txt grep it for your FAS username and follow the dependency chain. For human readable dependency chains, see https://packager.fedorainfracloud.org/ For all orphaned packages, see https://packager.fedorainfracloud.org/orphan Package (co)maintainers Status Change ansible-collection-community- orphan 0 weeks ago general apache-commons-configuration fnasser, mizdebsk, orphan, 3 weeks ago spike celt071 orphan 1 weeks ago compat-guile18jskarvad, mlichvar, orphan, 0 weeks ago tkorbar discord-irc orphan 0 weeks ago dnscaporphan 1 weeks ago dynafed andreamanzi, orphan 0 weeks ago elasticdump orphan 0 weeks ago electrum orphan 1 weeks ago environment-modules orphan 0 weeks ago ghc-pipes-safeorphan 0 weeks ago gtatool orphan 0 weeks ago hsqldb1 lef, orphan 0 weeks ago hub orphan, ralph, sgallagh 4 weeks ago jboss-jsf-2.1-api orphan 3 weeks ago jsonp lef, orphan 0 weeks ago legendsbrowserorphan 0 weeks ago libbind orphan 1 weeks ago metadata-extractor2 cquad, orphan3 weeks ago mingw-gtkglextepienbro, maci, orphan 1 weeks ago mocha nodejs-sig, orphan, patches 0 weeks ago netty-tcnativeorphan 0 weeks ago neurord neuro-sig, orphan0 weeks ago nodejs-assume nodejs-sig, orphan 0 weeks ago nodejs-block-stream nodejs-sig, orphan, patches 0 weeks ago nodejs-callback-streamorphan 0 weeks ago nodejs-chalk nodejs-sig, orphan, patches 0 weeks ago nodejs-clear-require orphan 0 weeks ago nodejs-co-mocha nodejs-sig, orphan 0 weeks ago nodejs-co-with-promiseorphan 0 weeks ago nodejs-coffee-coverageorphan 0 weeks ago nodejs-conventional-changelog-orphan 0 weeks ago preset-loader nodejs-csv-stringify orphan 0 weeks ago nodejs-debug-fabulous orphan 0 weeks ago nodejs-defaults humaton, nodejs-sig, orphan, 0 weeks ago vjancik nodejs-define-propertyorphan 0 weeks ago nodejs-figuresnodejs-sig, orphan 0 weeks ago nodejs-flush-write-stream orphan 0 weeks ago nodejs-fs-write-stream-atomic nodejs-sig, orphan, vjancik 0 weeks ago nodejs-gaze nodejs-sig, orphan, patches 0 weeks ago nodejs-glob nodejs-sig, orphan, patches 0 weeks ago nodejs-glob-expandorphan 0 weeks ago nodejs-intercept-require orphan 0 weeks ago nodejs-istanbul-lib-reportorphan 0 weeks ago nodejs-istanbul-reports orphan 0 weeks ago nodejs-jade nodejs-sig, orphan, patches 0 weeks ago nodejs-multipipe orphan
