Re: uscan roadmap
Le 2 décembre 2021 00:34:27 GMT+01:00, Paul Wise a écrit : >On Wed, 2021-12-01 at 12:53 +0100, Yadd wrote: > >> Personally I dislike redirectors. > >A redirector service is superior to including the redirector code >within uscan itself or within a debian/watch file, since when the >upstream website breaks the existing code, a service can be updated in >one place immediately, while uscan in Debian stable will be broken >until the next point release if it gets fixed at all and one in >debian/watch requires every package using the site to get updated. > Yes but the redirector often responded with 500 codes -- Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté.
Re: uscan roadmap
On 02/12/2021 10:16, Yadd wrote:
On 02/12/2021 00:34, Paul Wise wrote:
On Wed, 2021-12-01 at 12:53 +0100, Yadd wrote:
Personally I dislike redirectors.
A redirector service is superior to including the redirector code
within uscan itself or within a debian/watch file, since when the
upstream website breaks the existing code, a service can be updated in
one place immediately, while uscan in Debian stable will be broken
until the next point release if it gets fixed at all and one in
debian/watch requires every package using the site to get updated.
Yes but the redirector often responded with 500 codes
Another idea to have a compromise:
* uscan is released with versioned schemes (GitHub.json, sf.json,...)
* when launched, it tries to download new version from a new Debian API
(static json files)
* if no response or no new version, uscan uses its own scheme or a
previously downloaded update (verifying signature)
* if a new version is available from new redirector:
* it verifies GPG signature of new scheme
* if not OK, it warns and uses cached scheme
* if OK, it stores it with signature in ~/.cache/uscan/schemes
Then:
* no more redirector with an heavy load, but just some JSON schemes
statically stored
* uscan still works if Debian website doesn't respond
* GPG permits to be sure that scheme isn't corrupted (released files
are as protected as uscan itself because owned by root)
* easy update if upstream store changes its behavior: just to update
one JSON file
What do you think about this idea? Which GPG keys will be accepted?
More than one scheme could be used. Example:
Schemes: GitHub, stable
Schemes: GitHub, semver
GitHub scheme:
{
"Version": "1.0",
"filenamemangle": "auto",
"regex": "archive/.*/v?(@DEFAULT_VERSION_REGEX@)@ARCHIVE_EXT@$",
...
}
"stable" scheme:
{
"Version": "1.0",
"Default-Version-Regex": "(?:0|[1-9]\d*)(?:0|[1-9]\d*)*"
}
Re: uscan roadmap
On Thu, Dec 02, 2021 at 11:36:08AM +0100, Yadd wrote: > On 02/12/2021 10:16, Yadd wrote: > > On 02/12/2021 00:34, Paul Wise wrote: > > > On Wed, 2021-12-01 at 12:53 +0100, Yadd wrote: > > > > > > > Personally I dislike redirectors. > > > > > > A redirector service is superior to including the redirector code > > > within uscan itself or within a debian/watch file, since when the > > > upstream website breaks the existing code, a service can be updated in > > > one place immediately, while uscan in Debian stable will be broken > > > until the next point release if it gets fixed at all and one in > > > debian/watch requires every package using the site to get updated. So true > > > > Yes but the redirector often responded with 500 codes > > Another idea to have a compromise: > * uscan is released with versioned schemes (GitHub.json, sf.json,...) > * when launched, it tries to download new version from a new Debian API >(static json files) >* if no response or no new version, uscan uses its own scheme or a > previously downloaded update (verifying signature) >* if a new version is available from new redirector: > * it verifies GPG signature of new scheme >* if not OK, it warns and uses cached scheme >* if OK, it stores it with signature in ~/.cache/uscan/schemes > > Then: > * no more redirector with an heavy load, but just some JSON schemes >statically stored > * uscan still works if Debian website doesn't respond > > What do you think about this idea? Way too optimistic :-) The original problem was (and is) dealing with various upstream websites. Putting a translator, a redirector, between uscan and a single upstream website solves the problem for that particular website. IMNSHO is building (hard to upgrade and distribute) "solutions" for redirectors with 500s or whatever error effort at the wrong place. Explaining to the user (us, debian maintainers) what is happing is a better approach. Especial when the redirector can explain the 500 is due problems with the actual upstream website. Groeten Geert Stappers -- Silence is hard to parse
Re: uscan roadmap
Paul Wise writes: > I also wonder if it is time to split debian/watch out of Debian source > packages, since upstream download locations generally change > independently of the Debian package and so information about upstream > download locations probably should be maintained independently. I very much agree. I don't understand the logic of tying upstream checking to a particular version of a source package. The fact that some version of a package once upon a time could locate and download new upstream versions using a particular recipe is of no use if said recipe becomes outdated at any later time. It makes a lot more sense to provide this service in a way that allows it to be modified/updated/improved/fixed with no regards to the actual packages that may use it. That could be as simple as a uscan service with watch files that can be individually and independently modified. Best, Gard signature.asc Description: PGP signature
Re: uscan roadmap
Quoting Gard Spreemann (2021-12-02 12:31:30) > > Paul Wise writes: > > > I also wonder if it is time to split debian/watch out of Debian > > source packages, since upstream download locations generally change > > independently of the Debian package and so information about > > upstream download locations probably should be maintained > > independently. > > I very much agree. I don't understand the logic of tying upstream > checking to a particular version of a source package. The fact that > some version of a package once upon a time could locate and download > new upstream versions using a particular recipe is of no use if said > recipe becomes outdated at any later time. > > It makes a lot more sense to provide this service in a way that allows > it to be modified/updated/improved/fixed with no regards to the actual > packages that may use it. That could be as simple as a uscan service > with watch files that can be individually and independently modified. I find it helpful for our packages to include information about where and how (at the time of its release) that package was monitoring for upstream releases. It helps working decentralized - both for preparing packages for Debian and for working on Debian-derived packages, both without needing access to somewhere central for this "watch" information. Therefore I like the proposal to have Debian project scanners aggressively look for _newest_ watch file for a packaging project, including looking up declared Vcs-* hints for not-yet-released work. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: uscan roadmap
Jonas Smedegaard writes: > Quoting Gard Spreemann (2021-12-02 12:31:30) >> >> Paul Wise writes: >> >> > I also wonder if it is time to split debian/watch out of Debian >> > source packages, since upstream download locations generally change >> > independently of the Debian package and so information about >> > upstream download locations probably should be maintained >> > independently. >> >> I very much agree. I don't understand the logic of tying upstream >> checking to a particular version of a source package. The fact that >> some version of a package once upon a time could locate and download >> new upstream versions using a particular recipe is of no use if said >> recipe becomes outdated at any later time. >> >> It makes a lot more sense to provide this service in a way that allows >> it to be modified/updated/improved/fixed with no regards to the actual >> packages that may use it. That could be as simple as a uscan service >> with watch files that can be individually and independently modified. > > I find it helpful for our packages to include information about where > and how (at the time of its release) that package was monitoring for > upstream releases. It helps working decentralized - both for preparing > packages for Debian and for working on Debian-derived packages, both > without needing access to somewhere central for this "watch" > information. Would it make sense for a package to contain a snapshot of the relevant metadata in the hypothetical "centralized-and-often-updated watch service" at the time in enters into the archives? > Therefore I like the proposal to have Debian project scanners > aggressively look for _newest_ watch file for a packaging project, > including looking up declared Vcs-* hints for not-yet-released work. Indeed, that sounds like a better idea than what I suggest above! -- Gard signature.asc Description: PGP signature
Re: uscan roadmap
Quoting Gard Spreemann (2021-12-02 13:09:17) > > Jonas Smedegaard writes: > > > Quoting Gard Spreemann (2021-12-02 12:31:30) > >> > >> Paul Wise writes: > >> > >> > I also wonder if it is time to split debian/watch out of Debian > >> > source packages, since upstream download locations generally > >> > change independently of the Debian package and so information > >> > about upstream download locations probably should be maintained > >> > independently. > >> > >> I very much agree. I don't understand the logic of tying upstream > >> checking to a particular version of a source package. The fact that > >> some version of a package once upon a time could locate and > >> download new upstream versions using a particular recipe is of no > >> use if said recipe becomes outdated at any later time. > >> > >> It makes a lot more sense to provide this service in a way that > >> allows it to be modified/updated/improved/fixed with no regards to > >> the actual packages that may use it. That could be as simple as a > >> uscan service with watch files that can be individually and > >> independently modified. > > > > I find it helpful for our packages to include information about > > where and how (at the time of its release) that package was > > monitoring for upstream releases. It helps working decentralized - > > both for preparing packages for Debian and for working on > > Debian-derived packages, both without needing access to somewhere > > central for this "watch" information. > > Would it make sense for a package to contain a snapshot of the > relevant metadata in the hypothetical "centralized-and-often-updated > watch service" at the time in enters into the archives? Not _instead_ of current location: What I find helpful is to have the watch file available with the source package. I am unaware if there would be some benefit of _additionally_ embedding the watch file in binary packages (if that's what you meant). > > Therefore I like the proposal to have Debian project scanners > > aggressively look for _newest_ watch file for a packaging project, > > including looking up declared Vcs-* hints for not-yet-released work. > > Indeed, that sounds like a better idea than what I suggest above! Not sure if you noticed, but (since I won't steal credit) I basically emphasized Pabs' suggestion in last paragraph of what you previously quoted: Quoting Paul Wise (2021-12-02 00:47:44) > Alternatively, perhaps we could workaround outdated debian/watch files > by having vcswatch extract debian/watch files from the repo specified > in the Vcs-* URLs. - Jonas -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Re: uscan roadmap
Hi Le jeu. 2 déc. 2021 à 11:36, Yadd a écrit : > > Another idea to have a compromise: > * uscan is released with versioned schemes (GitHub.json, sf.json,...) > * when launched, it tries to download new version from a new Debian API > (static json files) > * if no response or no new version, uscan uses its own scheme or a > previously downloaded update (verifying signature) > * if a new version is available from new redirector: > * it verifies GPG signature of new scheme > * if not OK, it warns and uses cached scheme > * if OK, it stores it with signature in ~/.cache/uscan/schemes > What I don't like is that it will need time to check new profiles on a central site, which looks like an invitation for DoS situations. I propose a variation of this: an explicit "uscan --update" will update the profiles, and all other calls will use the known profiles. Cheers, J. Puydt
Re: uscan roadmap
Jonas Smedegaard writes: > Quoting Gard Spreemann (2021-12-02 13:09:17) >> >> Jonas Smedegaard writes: >> >> > Quoting Gard Spreemann (2021-12-02 12:31:30) >> >> >> >> Paul Wise writes: >> >> >> >> > I also wonder if it is time to split debian/watch out of Debian >> >> > source packages, since upstream download locations generally >> >> > change independently of the Debian package and so information >> >> > about upstream download locations probably should be maintained >> >> > independently. >> >> >> >> I very much agree. I don't understand the logic of tying upstream >> >> checking to a particular version of a source package. The fact that >> >> some version of a package once upon a time could locate and >> >> download new upstream versions using a particular recipe is of no >> >> use if said recipe becomes outdated at any later time. >> >> >> >> It makes a lot more sense to provide this service in a way that >> >> allows it to be modified/updated/improved/fixed with no regards to >> >> the actual packages that may use it. That could be as simple as a >> >> uscan service with watch files that can be individually and >> >> independently modified. >> > >> > I find it helpful for our packages to include information about >> > where and how (at the time of its release) that package was >> > monitoring for upstream releases. It helps working decentralized - >> > both for preparing packages for Debian and for working on >> > Debian-derived packages, both without needing access to somewhere >> > central for this "watch" information. >> >> Would it make sense for a package to contain a snapshot of the >> relevant metadata in the hypothetical "centralized-and-often-updated >> watch service" at the time in enters into the archives? > > Not _instead_ of current location: What I find helpful is to have the > watch file available with the source package. I am unaware if there > would be some benefit of _additionally_ embedding the watch file in > binary packages (if that's what you meant). > > >> > Therefore I like the proposal to have Debian project scanners >> > aggressively look for _newest_ watch file for a packaging project, >> > including looking up declared Vcs-* hints for not-yet-released work. >> >> Indeed, that sounds like a better idea than what I suggest above! > > Not sure if you noticed, but (since I won't steal credit) I basically > emphasized Pabs' suggestion in last paragraph of what you previously > quoted: > > Quoting Paul Wise (2021-12-02 00:47:44) >> Alternatively, perhaps we could workaround outdated debian/watch files >> by having vcswatch extract debian/watch files from the repo specified >> in the Vcs-* URLs. Apologies; I somehow thought that he meant auto-generating watch files from *upstream* VCSs. My bad, and thanks for clarifying! -- Gard signature.asc Description: PGP signature
Using release-monitoring.org [was: uscan roadmap]
On Thu, Dec 2, 2021 at 12:51 AM Paul Wise wrote: > > It might be a idea to look at how other distributions do checking for > new upstream releases and adopt some of their improvements. > > I note Fedora uses a service (that isn't Fedora specific) for this: > > https://release-monitoring.org > https://docs.fedoraproject.org/en-US/package-maintainers/Upstream_Release_Monitoring/ I think this would be the best path forward - it would probably be not easy given that it changes entirely how the current system works, but it might be well worth the effort. Working together with another distribution would share the work for the distro. I'm sure if we are willing to join them they would accommodate us if there are any changes we would require (e.g. login via salsa instead of a fedora account). > Another idea would be to use the Repology service to notice when other > distros include a newer version of a package than Debian does. > > https://repology.org/ This however I think is not a good idea. Repology is very nice to check what versions other distros have, but for projects that don't have any external language-specific package repository like e.g. python, it would mean that we could easily miss a new release (think small projects written in C that are not in any other distro) and wrongly formatted version from other distros would impact us (unlikely, but still bad in theory). And since it requires the same infrastructure changes as going with release-monitoring.org, it would be better to just use that. > I also wonder if it is time to split debian/watch out of Debian source > packages, since upstream download locations generally change > independently of the Debian package and so information about upstream > download locations probably should be maintained independently. Yes that makes sense, what I wonder is how much change is needed for putting watch files in a separate repo compared to going with release-monitoring.org (I don't know enough about the inner workings of our tools to answer this question). Anyway, if using release-monitoring.org is too much work or nobody is willing to do it, I like the proposals for version 5 so far. Regards, Stephan
/usr/bin/ld.so as a symbolic link for the dynamic loader
I'd like to provide an ld.so command as part of glibc. Today, ld.so can be used to activate preloading, for example. Compared to LD_PRELOAD, the difference is that it's specific to one process, and won't be inherited by subprocesses—something is that exactly what is needed. There is also some useful diagnostic output in --help, --list-diagnostics. Having ld.so as a real command makes the name architecture-agnostic. This discourages from hard-coding non-portable paths such as /lib64/ld-linux-x86-64.so.2 or even (the non-ABI-compliant) /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2 in scripts that require specific functionality offered by such an explicit loader invocation. I thought that commands with file extensions might be Policy violation. Policy actually talks about file extensions for programs installed in /usr/bin—but only for scripts. So it's technically okay. And today, there's already an ld.so manual page, although it's in section 8 and 1. (I think /usr/bin is still appropriate because running ld.so does not require special privileges.) The initial implementation will be just a symbolic link. This means that multi-arch support will be missing: the amd64 loader will not be able to redirect execution to the s390x loader. In principle, it should be possible to find PT_INTERP with a generic ELF parser and redirect to that, but that's vaporware at present. I don't know yet if it will be possible to implement this without some knowledge of Debian's multi-arch support in the loader. Upstream doesn't have those features (we only support /usr/lib vs /usr/lib64 and some minor variants of that), so integration might be lacking. If someone wants to upstream the multi-arch patches, that would be great. glibc now accepts submissions under DCO, so copyright assignment should no longer be an obstacle. Anyway, do you see any problems with providing /usr/bin/ld.so for use by skilled end users? Thanks, Florian
Re: Using release-monitoring.org [was: uscan roadmap]
On Thu, 2021-12-02 at 15:57 +0100, Stephan Lachnit wrote: > I think this would be the best path forward - it would probably be not > easy given that it changes entirely how the current system works, but > it might be well worth the effort. Working together with another > distribution would share the work for the distro. I'm sure if we are > willing to join them they would accommodate us if there are any > changes we would require (e.g. login via salsa instead of a fedora > account). At minimum we would need a way to map from release-monitoring.org package names to Debian source package names. Assuming they use Fedora source package names, then the Repology service provides such a mapping and we could presumably could get a periodic export of that. > This however I think is not a good idea. Repology is very nice to > check what versions other distros have, but for projects that don't > have any external language-specific package repository like e.g. > python, it would mean that we could easily miss a new release (think > small projects written in C that are not in any other distro) and > wrongly formatted version from other distros would impact us > (unlikely, but still bad in theory). I see using Repology as a complement to release-monitoring.org and uscan, not as an alternative to them. It enables use-cases that aren't possible with the other two. We automatically get version monitoring for packages that don't have other version monitoring mechanisms. We get monitoring of whether or not a particular package needs updating to a VCS snapshot instead of waiting for an official release. We get monitoring of versions even when upstream has moved to a different location not monitored by other mechanisms. There are probably other use-cases I can't think of right now. > And since it requires the same infrastructure changes as going with > release-monitoring.org, it would be better to just use that. I think it would need different changes, especially since Debian doesn't have the same realtime notifications stuff as Fedora does. > Yes that makes sense, what I wonder is how much change is needed for > putting watch files in a separate repo compared to going with > release-monitoring.org (I don't know enough about the inner workings > of our tools to answer this question). For the VCS idea it would be minimal, just vcswatch needs to also pull debian/watch files out of VCS repos with commits not yet pushed to Debian and then the version checking infra (zero idea where that went) needs to pay attention to that data. For fully moving debian/watch (and Homepage) out of Debian source packages there would need to be a lot more work, probably migrating to release-monitoring.org would be the way to go. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: uscan roadmap
On Thu, 2021-12-02 at 10:16 +0100, Yadd wrote: > Yes but the redirector often responded with 500 codes 500 codes probably just mean bugs in the redirector, which should be easy to fix for anyone with access to the redirector source code. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: Using release-monitoring.org [was: uscan roadmap]
On Fri, 3 Dec 2021, Paul Wise wrote: I think this would be the best path forward - it would probably be not easy given that it changes entirely how the current system works, but it might be well worth the effort. Working together with another distribution would share the work for the distro. I'm sure if we are willing to join them they would accommodate us if there are any changes we would require (e.g. login via salsa instead of a fedora account). At minimum we would need a way to map from release-monitoring.org package names to Debian source package names. Assuming they use Fedora source package names, then the Repology service provides such a mapping and we could presumably could get a periodic export of that. release-monitoring.org has the ability to configure distribution-specific names for each package. Take for example pycurl, which has mappings for Fedora, Alpine, and Timesys: https://release-monitoring.org/project/7973/ It appears there are 314 packages that already have Debian mappings. Scott
Re: Using release-monitoring.org [was: uscan roadmap]
On Thu, 2 Dec 2021, 23:17 Paul Wise, wrote: > At minimum we would need a way to map from release-monitoring.org > package names to Debian source package names. Assuming they use Fedora > source package names, then the Repology service provides such a mapping > and we could presumably could get a periodic export of that. > If I understand correctly, release-monitoring already offers such a mapping [1]. > I see using Repology as a complement to release-monitoring.org and > uscan, not as an alternative to them. It enables use-cases that aren't > possible with the other two. We automatically get version monitoring > for packages that don't have other version monitoring mechanisms. We > get monitoring of whether or not a particular package needs updating to > a VCS snapshot instead of waiting for an official release. We get > monitoring of versions even when upstream has moved to a different > location not monitored by other mechanisms. There are probably other > use-cases I can't think of right now. > Hm, I can't really think of an example where such a thing couldn't also be implemented in release-monitoring.org. > > Yes that makes sense, what I wonder is how much change is needed for > > putting watch files in a separate repo compared to going with > > release-monitoring.org (I don't know enough about the inner workings > > of our tools to answer this question). > > For the VCS idea it would be minimal, just vcswatch needs to also pull > debian/watch files out of VCS repos with commits not yet pushed to > Debian and then the version checking infra (zero idea where that went) > needs to pay attention to that data. > Oh right, that actually sounds pretty smart. > For fully moving debian/watch (and Homepage) out of Debian source > packages there would need to be a lot more work, probably migrating to > release-monitoring.org would be the way to go. > Just one quick idea I had: what about a "fake" uscan backend? I.e. something like `Version: release-monitoring.org` in d/watch. In that case uscan will launch an external program that fetches the data from there and gives it back to uscan, so that other tools stay unaffected until a full transition is done. In case there are others interested in this approach, I would be down to do some coding (when I find time). Regards, Stephan [1] https://release-monitoring.org/static/docs/user-guide.html#creating-new-distribution-mapping
Re: Using release-monitoring.org [was: uscan roadmap]
On Thu, 2021-12-02 at 23:36 +0100, Stephan Lachnit wrote: > If I understand correctly, release-monitoring already offers such a > mapping [1]. It seems like the Ayanita distro mapping needs to be done manually once per package, while using the Repology data would automatically get us the mapping for each existing package and all future packages. > Hm, I can't really think of an example where such a thing couldn't > also be implemented in release-monitoring.org. None of the three use-cases I listed can be done by it AFAICT. It can't check things that it doesn't have a check for, while individual package maintainers in various distros will update their packages and Repology will notice the new versions. It presumably doesn't look at the versions for all distros, so it can't do the cross-distro VCS snapshot choice check, while individual package maintainers in various distros know their packages well and might upgrade to a VCS snapshot in their distro, which Repology notices. It also isn't going to check locations it doesn't check yet, while individual package maintainers in other distros might do that after noticing their package hasn't been updated recently and then going searching for a new upstream and updating, which Repology notices. > Just one quick idea I had: what about a "fake" uscan backend? I.e. > something like `Version: release-monitoring.org` in d/watch. In that > case uscan will launch an external program that fetches the data from > there and gives it back to uscan, so that other tools stay unaffected > until a full transition is done. Excellent idea, that would be great to have. The one issue I can think of with using release-monitoring.org is that Debian becomes more reliant on an external service, while currently we are completely independent of other distros for version checking. Converting the release-monitoring.org check to a watch file might be an alternative to using it directly that maintains our independence. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Re: /usr/bin/ld.so as a symbolic link for the dynamic loader
Florian Weimer wrote: > I'd like to provide an ld.so command as part of glibc. Will this happen in glibc upstream or just in Debian? > Today, ld.so can be used to activate preloading, for example. > Compared to LD_PRELOAD, the difference is that it's specific to one > process, and won't be inherited by subprocesses—something is that > exactly what is needed. That appears to be activated like this: /lib64/ld-linux-x86-64.so.2 --preload /usr/lib/x86_64-linux-gnu/libeatmydata.so.1.3.0 /bin/ls > Anyway, do you see any problems with providing /usr/bin/ld.so for use > by skilled end users? It means more folks get exposed to ld.so features, which might mean more support and feature requests for glibc upstream,. For example the set of features provided by environment variables is different to the set of features provided by command-line options. -- bye, pabs https://wiki.debian.org/PaulWise signature.asc Description: This is a digitally signed message part
Work-needing packages report for Dec 3, 2021
The following is a listing of packages for which help has been requested through the WNPP (Work-Needing and Prospective Packages) system in the last week. Total number of orphaned packages: 1247 (new: 6) Total number of packages offered up for adoption: 184 (new: 0) Total number of packages requested help for: 61 (new: 0) Please refer to https://www.debian.org/devel/wnpp/ for more information. The following packages have been orphaned: puppet-beaker (#1001000), orphaned today Description: test harness providing platform abstraction and VM provisioning Installations reported by Popcon: 2 Bug Report URL: https://bugs.debian.org/1001000 ruby-beaker-hostgenerator (#1000996), orphaned today Description: command line utility designed to generate beaker host config files Reverse Depends: puppet-beaker Installations reported by Popcon: 3 Bug Report URL: https://bugs.debian.org/1000996 ruby-in-parallel (#1000995), orphaned today Description: lightweight Ruby library with very simple syntax for parallelization Reverse Depends: puppet-beaker Installations reported by Popcon: 4 Bug Report URL: https://bugs.debian.org/1000995 ruby-open-uri-redirections (#1000994), orphaned today Description: openuri patch to allow redirections between HTTP and HTTPS Reverse Depends: puppet-beaker Installations reported by Popcon: 4 Bug Report URL: https://bugs.debian.org/1000994 ruby-pry-byebug (#1000993), orphaned today Description: step-by-step debugging and stack navigation capabilities in pry using byebug Reverse Depends: puppet-beaker Installations reported by Popcon: 7 Bug Report URL: https://bugs.debian.org/1000993 ruby-stringify-hash (#1000992), orphaned today Description: ruby hash object that treats symbols and strings interchangeably Reverse Depends: puppet-beaker Installations reported by Popcon: 3 Bug Report URL: https://bugs.debian.org/1000992 1241 older packages have been omitted from this listing, see https://www.debian.org/devel/wnpp/orphaned for a complete list. No new packages have been given up for adoption, but a total of 184 packages are awaiting adoption. See https://www.debian.org/devel/wnpp/rfa_bypackage for a complete list. For the following packages help is requested: apache2 (#910917), requested 1146 days ago Description: Apache HTTP Server Reverse Depends: apache2 apache2-ssl-dev apache2-suexec-custom apache2-suexec-pristine backuppc bfh-container-server courier-webadmin cvsweb debbugs-web doc-central (138 more omitted) Installations reported by Popcon: 99486 Bug Report URL: https://bugs.debian.org/910917 aufs (#963191), requested 530 days ago Description: driver for a union mount for Linux filesystems Reverse Depends: fsprotect Installations reported by Popcon: 9881 Bug Report URL: https://bugs.debian.org/963191 autopkgtest (#846328), requested 1828 days ago Description: automatic as-installed testing for Debian packages Reverse Depends: debci-worker sbuild-qemu Installations reported by Popcon: 1240 Bug Report URL: https://bugs.debian.org/846328 balsa (#642906), requested 3721 days ago Description: An e-mail client for GNOME Reverse Depends: balsa Installations reported by Popcon: 650 Bug Report URL: https://bugs.debian.org/642906 cargo (#860116), requested 1696 days ago Description: Rust package manager Reverse Depends: dh-cargo rust-all Installations reported by Popcon: 2680 Bug Report URL: https://bugs.debian.org/860116 courier (#978755), requested 336 days ago Description: Courier mail server Reverse Depends: courier-faxmail courier-filter-perl courier-imap courier-ldap courier-mlm courier-mta courier-pcp courier-pop courier-webadmin couriergrey (3 more omitted) Installations reported by Popcon: 933 Bug Report URL: https://bugs.debian.org/978755 cron (#984736), requested 270 days ago Description: new maintainer need Reverse Depends: apticron autolog backintime-common btrfsmaintenance buildd checksecurity clamtk cricket email-reminder exim4-base (20 more omitted) Installations reported by Popcon: 209327 Bug Report URL: https://bugs.debian.org/984736 cyrus-imapd (#921717), requested 1028 days ago Description: Cyrus mail system - IMAP support Reverse Depends: cyrus-admin cyrus-caldav cyrus-clients cyrus-dev cyrus-imapd cyrus-murder cyrus-nntpd cyrus-pop3d cyrus-replication Installations reported by Popcon: 423 Bug Report URL: https://bugs.debian.org/921717 dbab
